Interact with a STM32 chip's memory in C

Question

I would like to interact with a STM32 chip's memory, STM32L476, first to read and store its electronic signature (MCU_ID) and then to write data in its memory. I am using a STM32QFP64 socket linked to a JTAG ST-LINK.
I am quite good in C but really beginning embedded programming so I chose Atollic Studio IDE because it seemed quite complete and was based on Eclipse which I had already used prior.

My problem is that I can't find some sort of documentation listing the functions, variables etc. I could use to interact with the chip. I have searched in nearly all the PDFs given on the ST site, read ST's GitHub, but since I am a beginner I could have missed those information for I did not know what what I am searching for looks like.

The code below is irrevelant and completely imagined, but it could help understanding what I am trying to do, which I picture somehow like this :

#define MEMORY_ADRESS_MCU_ID FFFFF // A memory adress ( I should be able to find it in STM32L476 documentation)
#define MEMORY_ADRESS_TO_WRITE FFFF // Same

unsigned extractMCUID() {

   return READ_IN_MEMORY(MEMORY_ADRESS_MCU_ID); // Returns the ID stored in a particular memory adress

}

void writeData(char* d) {

   WRITE_IN_MEMORY(MEMORY_ADRESS_TO_WRITE, d); // Writes data in specified memory adress

}

Thus, in this case and even more generally :

1) Where should I look for such documentation ?

2) Does those functions and variables change depending on what STM32 chip I am dealing with ?

3) Where could I have found the answers to 1) and 2) if not on StackExchange ?

Just simply read and write the memory addresses you need using pointers. Wrap them in functions if you like. Everything is memory mapped so as long as you are in Privileged Mode you can access everything (you will be in Privileged unless you have expressly changed it.) As for the documentation, the relevant STM32Fxxx Reference Manual and Datasheet should give you everything. Anything else would be in the ARM Cortex-M4 reference manual / generic user guide. — Realtime Rik, May 05 '17 at 12:50
which "memory" are you after? flash or ram or other? if ram you simply write to it, use a pointer use an assembly function to perform the actual write, whatever you choose, the st docs show the address space, use that address (space), of course dont write over your programs variables (shown in the map readelf or objdump or other will show). — old_timer, May 05 '17 at 12:57
Strong recommendation from someone who worked with STM32 for years: **Do not use the STlib/HAL rubbish**. It just complicates your software, makes debugging harder and adds another unnecessary layer you have to keep in mind. It provides not benefit. Said that, you should get a tutorial/book about embedded programming. Get tthe referencee manuals from the ST site and work through them to understand the hardwaare and peripherals. Please understand we are not a tutoring site. If you have a **specific** question, though, feel free to ask. Just read [ask] and follow the advice. — too honest for this site, May 05 '17 at 12:58
the answers are on stackexchange, I know I have written several examples, if ram then all cortex-ms so far I have messed with ram starts at 0x20000000 its length does vary based on what part you buy. if flash, then on the stm32 so far it starts at 0x08000000 but you have to do more than just write there, size varies. all the documentation you need for any o fthis is at STs website and they do a better than average job with their docs. — old_timer, May 05 '17 at 12:59
What you need is SDK: Software Developement Kit. You can find STM32, for example, [on St webstite](http://www.st.com/en/development-tools/stm32-software-development-tools.html?querycriteria=productId=SC2106) — LPs, May 05 '17 at 13:03
@Olaf Indeed, I know this is not a tutoring site, my question was more regarding where to find some good tutoring (which has already been done on other topics of StackOverflow) and documentation. I am sorry if this is off-topic, but it didn't seemed like it was to me. — Badda, May 05 '17 at 13:03
@Badda: Asking for tutorials is also OT here. Sorry for that. But there are some good general books about embedded ARM Cortex-M programming. Plus the ref-man and you are done. Just use the CMSIS and register headers from the ST package, but not the rest. It will safe you a lot of time (and greatly enhance performance, which is an issue with embedded). — too honest for this site, May 05 '17 at 13:05
No need to be sorry, the question deserves to be down-voted or flagged if it is not revelant on this site, althought the answers I have read so far are very interesting and might help a lot of people. I will try to understand all those information you gave me. Thanks. — Badda, May 05 '17 at 13:15
IIRC the ST HAL comes with some manner of Doxygen documentation together with the code. Very brief documentation... — Lundin, May 05 '17 at 13:30
You should understand that "interacting with memory" is pretty much all you can do in C. That is not your problem and your question should be reformed. You are asking very specifically "How can I read the STM32 MCU ID and write it to a specific memory location?" It is not clear however which part of that you are having trouble with or both. One part is device specific, the other pretty generic. For your part the ID is already memory mapped at `0xE0042000` - it is not clear why you need to copy it to some other location. `*((uint32_t*)MEMORY_ADRESS_TO_WRITE) = *((uint32_t*)0xE0042000) ;` — Clifford, May 05 '17 at 16:02
Just ask the question, rather than asking where to find the answer for yourself; so is a Q&A not a library index. If it is relevant, a good answer will include references to documentation in any case; you will be both get your fish, and be taught to fish; but the latter is not the primary purpose os SO. You will get far more interesting answers that way rather than simply RTFM. — Clifford, May 06 '17 at 06:24
@toohonestforthissite - You may be right about the ST standard libs when you wrote your comment (sample code being rubbish, 2017). I had a glance at those old libs, too, and wasn't convinced either. Nevertheless, ST has made a new HAL platform that is quite handy if you want to change the STM32 family quickly (actually two of them, "HAL" is more portable and "LL" is more CPU-efficient). Those libs are meant for "rapid prototyping" and in my opinion, they serve quite well in quickly getting a system "flying", and some rough understanding. Afterwards, you're free to replace the lib by your own. — HelpingHand, Apr 09 '20 at 16:49
@HelpingHand (A late) thanks for the info, maybe I'll check them someday. However, normally I nevertheless have to read the RefMan for hardware capabilities anyway and it does not make much difference whether I call a function or directly write a register. Also a general problem arises with my projects using such libs is that I prefer using an actor-based architecture and those libraries are normally tailored to the classic threaded model. Expecially with strong memory protection and e.g. partial restart on failure, etc., the latter adds massive complexity and overhead to the user-code. — too honest for this site, Mar 06 '21 at 17:58
@toohonestforthissite - I believe I can understand you since I also start from the RefMan usually, and I also head for actor-based arch. (except for the few cases when the overall executable is so tiny that this is overshoot...). My strategy is then to assign each HW/HAL instance to an actor (task) exclusively. I agree that sharing CubeHAL lib resources (say, a UART, an ADC or whatever) between multiple actor tasks is not recommendable. But this does not depend on the question whether the underlying hardware is abstracted by some HAL or not. — HelpingHand, May 08 '21 at 16:56

score 1 · Answer 1 · answered May 05 '17 at 12:52

1

You may want to have a look here: http://www.openstm32.org

This part may give you a hint: char in_ccram_buffer[1024] __attribute__((section("ccmram")));

I have something similar in my AVR code:

 const uint16_t tempTable[42] __attribute__((section(".eeprom"))) = ...

works a charm.

answered May 05 '17 at 12:52

Sokre

114
6

Write comment instead answer as this is not answer. – unalignedmemoryaccess May 05 '17 at 12:57
1

He does not have enough reputation to comment though, and it did help me a bit. – Badda May 05 '17 at 12:59
@Badda: Non sequitur. A comment must not be an answer. There is a reason you need some rep to comment. – too honest for this site May 05 '17 at 14:07
". Any answer that gets the asker going in the right direction is helpful, but do try to mention any limitations, assumptions or simplifications in your answer. Brevity is acceptable, but fuller explanations are better." This might not be the appropriate place to talk about this, but I don't see how this is not an answer. It is not really satisfying, but not all answers are. – Badda May 05 '17 at 14:15
@tilz0R Question being where to find info if not here, a link to community web page is definitely an answer and not a comment. One may of course argue if the answer is correct, complete or of decent quality, but it is still an answer. Actually, some of the comments posted in reply to original post are also answers, at least partial ones and should not have been posted as comments. – Sokre May 05 '17 at 16:31

kkrambo · Accepted Answer · 2017-05-10T13:25:32.180

STM publishes several types of documents for each MCU and it's difficult for me to guess which document will contain the piece of information that I'm looking for. So I search within the documents for related key words until I narrow in on the information. The two most important documents are the Datasheet and the Reference Manual so I always start with them.

In this case I started searching the Datasheet for "MCU_ID" and found nothing so I searched for the more generic "ID" and found it associated with the more specific keyword "unique". I searched the Datasheet for "unique" but didn't find the register address information. So then I searched the Reference Manual for "unique ID" and found the base address for the register in section 49.1 on page 1808.

Yes, details like this can change from one STM MCU to the next so you need to ensure you're using the correct Datasheet and Reference Manual. However, STM provides a Hardware Abstraction Layer (HAL) called STM32Cube, which abstracts away MCU specific details like this and allows you to call more generic functions which are MCU independent.

Edit: I may have pointed you to the wrong ID register. Clifford points out in the comments that there is an MCU device ID register at address 0xE0042000. This MCU device ID register is different from the Unique device ID register and it's described in section 48.6.1 on page 1782 of the Reference Manual.

Interesting. Thanks for explaining what HAL is, althought a comment on the question specifies that one should avoid using it, I can see how it might be useful from time to time. — Badda, May 05 '17 at 13:20
Opinions vary. I agree that the STM HAL adds a layer of complication underneath and a hit to performance. But it does provide benefits such as abstraction from low-level details and portability across STM MCUs. For beginners especially, I believe it's easier to learn to use the HAL than it is to learn to work without it. — kkrambo, May 05 '17 at 13:47

Interact with a STM32 chip's memory in C

2 Answers2

Linked