A bare metal programming guide(github.com)
github.com
A bare metal programming guide
https://github.com/cpq/bare-metal-programming-guide
3 comments
The linker script specifies that .data section starts where 192k RAM region starts - in other words, addresses of all variables, etc, are in the RAM memory range.
But the firmware image (that resides on flash), which has .text and .data concatenated, has that .data section in Flash region, obviously. So we have .data section residing in Flash region, but all its addresses in the RAM memory range. That's why it is necessary to copy it over manually.
Hope this is clear... Let me know if not!
But the firmware image (that resides on flash), which has .text and .data concatenated, has that .data section in Flash region, obviously. So we have .data section residing in Flash region, but all its addresses in the RAM memory range. That's why it is necessary to copy it over manually.
Hope this is clear... Let me know if not!
I understand now, thanks for clarifying!
If you would like things to be explained in more detail (and take you to the next level); i highly recommend Embedded Systems Architecture: Explore architectural concepts, pragmatic design patterns, and best practices to produce robust systems by Daniele Lacamera. The name is a bit of a misnomer; it is basically a ground up introduction to bare-metal programming all the way up to writing your own Task scheduler/OS.
Thank you.
I've been looking for a guide like this for a while now. Thank you very much for sharing it!!
Very nice and succinct!
Thanks for sharing.
Thanks for sharing.
> Our firmware will be copied to the flash region at offset 0x8000000, but our data section should reside in RAM
> therefore our _reset() function should copy the contents of the .data section to RAM.
> Also it has to write zeroes to the whole .bss section.
I'm confused by this. The linker places these sections on flash memory. How does the compiler know to use section we copied to RAM for the variables in the code?