Hard fault prevents any further uploads - J27 for STM32F4 Discovery?

[PaulBeaney]

Hi,

 

Been a MIDIbox user for a few years now (thanks, TK!) but this is the first time I've not found my question already answered somewhere.

 

Having been on MIOS8 for so long, I recently got an STM32F4 Discovery to start work on replacing my existing board.  It was all going really well until I tried add an RTOS task with (I presume) not enough stack memory allocated, resulting in a "hard fault at PC=0x00000000".

 

I've amended my code to allocate a bigger stack, but now I seem to have no way to upload any more.  The error condition occurs very soon after bootup (in App_Init()), but using the reset button on the Discovery board doesn't seem to trigger an upload request - MIOS Studio doesn't respond in any case.  I'm guessing my config must have fastboot turned on.

 

I found a mention of the "BSL Hold" jumper here http://www.ucapps.de/mios32_bootstrap_newbies.html, but that seems to be for the LPC17 board only. Is there any equivalent on the Discovery??

 

Hoping someone can help!

 

Regards,

 

- Paul

 

 

[PaulBeaney]

Ah, just realised that I didn't actually need to make a first post - I've just this moment seen the bit on that page I linked to that mentions using the User and Reset buttons to force bootloader mode... and it works a treat!

[TK.]

This reminds me, that I wanted to implement a fallback mode, so that USB MIDI access is still possible, and also some terminal commands for debugging are available (e.g. to dump a memory map for stack analysis)

 

Maybe a nice weekend project :)

 

Best Regards, Thorsten.

[PaulBeaney]

Whilst I can now recover the board after a crash, I am still getting these "hard fault at PC=0x00000000" errors whenever I try and create an RTOS task.

 

Running umm_info() before attempting to launch the task gives this: 

 

[24733.109] Dumping the umm_heap...

[24733.109] |0x20000910|B     0|NB     0|PB     0|Z     0|NF     0|PF     0|

[24733.110] |0x20000910|B     0|NB     0|PB     0|Z  2048|NF     0|PF     0|

[24733.110] Total Entries     0    Used Entries     0    Free Entries     0

[24733.110] Total Blocks   2048    Used Blocks      0    Free Blocks   2048

[24733.110] Size of umm_heap is 24576 bytes, used: 0 bytes, free: 24576 bytes

 

I have fiddled with the values of the stack size in the task creation and the only extra information I have been able to ascertain is that if I request too much memory, or none at all, then there is no crash (but nothing useful happens either), which seems to indicate that the crash is only happening when there *is* available memory.

 

e.g. 

xTaskCreate(TASK_LED_Update, (signed portCHAR *)"LED", 4*1536, NULL, PRIORITY_TASK_LED_UPDATE, NULL); gives the error in MIOS Studio console:

[25057.685] Can't allocate  2049 blocks at   305

 

Any ideas welcome!

[TK.]

By default following stack size is used (see programming_models/traditional/FreeRTOSConfig.h):

#ifndef MIOS32_MINIMAL_STACK_SIZE
#define MIOS32_MINIMAL_STACK_SIZE 1024
#endif

...

#define configMINIMAL_STACK_SIZE            ( ( unsigned portSHORT ) (MIOS32_MINIMAL_STACK_SIZE/4) )

as you can see, the byte size has to be divided by 4, because FreeRTOS counts the memory word-wise

 

Which means, that you tried to allocate 24580 bytes - which fails (for obvious reasons).

Note that programming_models/traditional/main.c creates two additional tasks for MIDI and other purposes, which need memory from the heap as well (1024 bytes per task as defined with MIOS32_MINIMAL_STACK_SIZE)

 

Best Regards, Thorsten.