Skip to main content
Associate II
July 23, 2024
Solved

STM32H750 Copy to ITCM without GCC "Copy to NULL" warning

  • July 23, 2024
  • 3 replies
  • 1452 views

I see lots of posts with folk struggling to get code into ITCM, but not the (sorta) problem I have after getting things working.  It is just a compiler warning, but I'd like to find an elegant way of handling it.

The issue is I am using memcpy to copy my code intended for the ITCM from external flash to ITCM space.  All is good and it works, but since the start of ITCM is at address 0, GCC understandably questions my intentions as I'm doing a memcpy to NULL!  It's just a warning I've been living with, but I'm in a clean-up phase and would like to clear this warning.

 

Options I've considered but none seem a clean solution:

1) Use -Wnonnull option: Would work, but the warning overall is a good one and not a good idea to disable for the entire project.  There might be some way to disable it just for the file making the call, but still--ick.

2) Manually copy the first 4 bytes (or something like that) and then use memcpy for addresses 4+.  This seems the least ugly, but still...

3) Use a hardware DMA.  I presume this would work.  Speed isn't an issue and I'd still just be waiting for the DMA to finish before continuing.  Seems an overly complicated way to avoid a compiler warning.

 

What have other folk done?  I'm certainly not the first one trying to solve this issue and it isn't even unique to the H750.

will

This topic has been closed for replies.
Best answer by Tesla DeLorean

If you implement CPU clock (PLL, buses) and memory interfaces in SystemInit(), as ARM intended, then the C runtime startup code can copy from any memory and at top speed.

I'd suspect if you have the memcpy() in a function passed a void* pointer from the level above, I'm not sure it's going to NULL check that.

3 replies

Tesla DeLorean
Guru
July 24, 2024

Have the Linker generate the code/data in the ITCMRAM region, stage it in FLASH, and move it there in the startup.s code..

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
Will5Author
Associate II
July 24, 2024

Tesla:  Good solution, but alas the code for ITCM is in an external QSPI NOR flash, not the main flash, so I have to do the copying much later in the boot process, after the code that initializes the QSPI NOR controller and external flash itself.  Moving all the QSPI code to assembly is a bit much.

Still, that is a fourth option, even if not in startup.s, a simple assembly language routine call to do the copying won't generate a C warning!

 

will

Tesla DeLorean
Tesla DeLoreanBest answer
Guru
July 24, 2024

If you implement CPU clock (PLL, buses) and memory interfaces in SystemInit(), as ARM intended, then the C runtime startup code can copy from any memory and at top speed.

I'd suspect if you have the memcpy() in a function passed a void* pointer from the level above, I'm not sure it's going to NULL check that.

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
Will5Author
Associate II
July 25, 2024

Tesla: I thought the compiler/optimizer would be smart enough to see me passing a NULL as a constant parameter to a routine with the memcpy() in it, but it didn't call me out!  That by far is the most elegant solution!

 

Thanks!

 

will