cancel
Showing results for 
Search instead for 
Did you mean: 

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

Will5
Associate II

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

1 ACCEPTED SOLUTION

Accepted Solutions

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
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

5 REPLIES 5

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
Up vote any posts that you find helpful, it shows what's working..

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:  ...and BTW, just confirming I already do the first part of what you said, I compile for ITCM, then tell the linker to put the binary image in SPI NOR space.  I just reserve the first 64K of SPI NOR space for the ITCM image, then after that is SPI NOR XIP code.  After setting up the SPI NOR, then I simply memcpy 64K from the start of SPINOR to ITCM.

 

will

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
Up vote any posts that you find helpful, it shows what's working..
Will5
Associate II

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