FreeRTOS+TCP Simple network interfaces STM32F429

Kernel
21

billskeen68 wrote on Tuesday, October 04, 2016:

That is the part I am not sure of where/what to do. Does this code go in core_hal.c, somewhere near/before the vTaskStartScheduler();?

uint32_t *ACTLR = (uint32_t *)0xE000E008;
*ACTLR |= 2; //setting the DISDEFWBUF bit (bit 1)

int main(void)
{
init_malloc_mutex();
xTaskCreate( application_task_start, “app_thread”, APPLICATION_STACK_SIZE/sizeof( portSTACK_TYPE ), NULL, 2, &app_thread_handle);

 uint32t ACTLR = (uint32t )0xE000E008;
*ACTLR |= 2; //setting the DISDEFWBUF bit (bit 1)

vTaskStartScheduler();

/* we should never get here */
while (1);

return 0;

}

How do I determine if I need configAssert and where does it go?

Sorry to be so dumb here, but learning as I go.

22

davedoors wrote on Tuesday, October 04, 2016:

in main:

uint32_t * ACTLR = ((uint32_t*)0xE000E008)
uint32_t temp;

temp = *ACTLR;
temp |= 0x02;
*ACTLR = temp; // bit now set
23

billskeen68 wrote on Tuesday, October 04, 2016:

Okay, I added the 2 lines of code to the core_hal.c main function, recompiled debug version and now waiting for breakpoint hit. Interesting to note that this slowed down BLE device detection considerably. What used to take less than 30 seconds at startup now takes 4-5 minutes.

24

edwards3 wrote on Wednesday, October 05, 2016:

from the FreeRTOS page “turning off write buffering by setting the DISDEFWBUF bit (bit 1) in the Auxiliary Control Register (or ACTLR) will result in the imprecise fault becoming a precise fault, which makes the fault easier to debug, albeit at the cost of slower program execution.”

25

billskeen68 wrote on Wednesday, October 05, 2016:

Thanks MEdwards. I did read that. I just was not expecting 10x slower. Now that I have made that change, I have not had a hardfault since. Not sure what to do now, so going back to board mfg for suggestions.

Thank all for the help.