Electronics > Microcontrollers

32F4 CCM memory - gotchas?

<< < (3/4) > >>

technix:

--- Quote from: peter-h on May 13, 2021, 05:17:42 am --- 800d032:   4b23         ldr   r3, [pc, #140]   ; (800d0c0 <vTaskSwitchContext+0xa0>)
 800d034:   2200         movs   r2, #0
 800d036:   601a         str   r2, [r3, #0]
      taskSELECT_HIGHEST_PRIORITY_TASK();
 800d038:   4b22         ldr   r3, [pc, #136]   ; (800d0c4 <vTaskSwitchContext+0xa4>)
 800d03a:   681b         ldr   r3, [r3, #0]
 800d03c:   9303         str   r3, [sp, #12]

It bombs in prvPortStartFirstTask.

--- End quote ---
How does the registers look?

peter-h:
Normal, PC and SP etc.



The stack has been decremented only very slightly.

Siwastaja:
Look at the registers in the SCB block. Specifically, if you are hardfaulting, you want to look at the HFSR, which will tell you why it hardfaulted. Usually the reason is something else that escalated into hardfault though so you need to go further.

This is all described in ARM core manuals, go step by step to actually find the reason. It's a bit daunting first; it may take hours to days to learn how to find the reason (and finding the cause usually takes a few steps), but once you get to the actual reason, the fix is usually a 10 second job.

This seems quite usable tutorial regarding fault finding: https://interrupt.memfault.com/blog/cortex-m-fault-debug

peter-h:
I suspect there is something falling over in FreeRTOS, around here



The MSP and PSP are pointing at the CCM and the main RAM respectively, which is what I would perhaps expect, because the RTOS gives each thread a stack allocated in the heap which is in main RAM.

taskCHECK_FOR_STACK_OVERFLOW is not defined (the stuff is in stack_macros.h)

xpsr
   Hex:0x81000003
   Decimal:-2130706429
   Octal:020100000003
   Binary:10000001000000000000000000000011


I wonder if the RTOS is expecting the entry stack to be above the heap? The heap could go into the CCM, perhaps.

In the linker script there is this test which will obviously not work for the stack being in CCM




but I don't know how to fix this, or how to move the heap (32k currently) into CCM. Well, perhaps the order in the linkfile is what determines that (heap going after bss, which would be normal) so I did this



and hey... it is running! 10k left in CCM.

The gotcha is that DMA cannot be used for anything on the main stack, the RTOS process stacks (which come out of the heap), or the heap!

There is a remaining issue that when I look at some RTOS process, I see the process stack is still in main RAM. No idea how it is getting there; the RTOS is supposed to be allocating process stacks out of the heap.



That has been solved. I discovered the original programmer left a second 48k heap inside the RTOS as a static, IOW allocated out of bss:



which also explains the huge BSS usage... That RTOS stuff was supposed to be malloced out of the main heap.

peter-h:
Well, I got it all going now. Thank you all.

There is a dramatic performance improvement too. Since I am not currently using ethernet (which has its own DMA controller and uses static buffers in BSS) this is probably due to the CPU doing stuff like cache filling without affecting data operations. On one metric there is a 5x speedup.

It does look like FreeRTOS doesn't like its own stack memory (which is now allocated out of a 48k static buffer sitting in CCM) to be in a different section (lower address) than the general stack (which is also now in CCM). I was seeing the MSP at 0x1... and the PSP at 0x2... and it didn't like that.

Navigation

[0] Message Index

[#] Next page

[*] Previous page