Jump to content

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


PaulBeaney
 Share

Recommended Posts

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

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...