Hi all
I am working on STM32F030R8 chip,using Keil MDK. For every unit, it carries it own characteristics, and hence for every calibrated unit, I need to re-flash a part of the flash to put the characteristic in.
For example, the characteristics is an array of bytes, so I create a characteristic.c file to put the data at specific location: (0x0800F000)
const unsigned char array[] __attribute__(at(0x0800F000)) = {1, 2, 3, 4, 5, 6} ;
The compiler will generates object file: characteristic.o
Now the question is, how can I get this object file converted to a hex file, that I can just page flash into the target? I think there should have simple command from the MDK suite.
Thanks
Calvin
The actual characteristic is far more than this. It is a complicated multiple layers of structures and sub-structures.
Even so, the compiler is entirely the wrong tool for that kind of job. If you need to patch your hex files, then you should exactly that: patch them. Not generate new ones from scratch, for every unit.
Even though it's probably possible to automate the compiler to the extent you have in mind, it's almost certainly not an option to run the compiler for every unit you produce. It would be too slow, too expensive, and there would be nobody around at the production site who knows how to use it.
Hans-Bernhard Broeker, you are right, compiler is very clever on this, and I am aware of this. My code to address this is to use a pointer to the structure, so the master code is like:
#define structurePtr (const structureType *)(0x0800F000) // my intended calibration structure location
in the code, I reference the member as: structurePtr->entity.member1 ......
So the compiler cannot do the clever thing that you mentioned, and is forced to address the corresponding location for the data.
Here is my solution to my own question, with this simple example:
create the test.c file containing a single line:
const unsigned char array[] __attribute__((at (0x0800F000))) = {1, 2, 3, 4, 5, 6} ;
create a batch file test.bat containing 3 lines: armcc test.c armlink --output test.axf test.o fromelf --i32 --output test.hex test.axf
The 1st line armcc complies the c file with test.o output (with warning, can be ignored) The 2nd line links the file to test.axf (with warning, can be ignored) The 3rd line create the hex file that I want.
running the batch file gets instant result, even with my complicated structure.
Then incorporate STM's flash Loader Demo (bootloader demo from STM - STMFlashLoader.exe) into the batch file as the fourth line to complete the job by patching the flash page.
Wow. Where do you buy such hammers? I've got a pile of nuts here to crack.
modified the 1st line in the batch file to make the 2nd line obsolete:
armcc -o test.axf test.c
So the final batch file of 3 lines finish the job in one go:
armcc -o test.axf test.c fromelf --i32 --output test.hex test.axf STMFlashLoader.exe -c --pn 4 --br 115200 -i STM32F0_5x_3x_64K --fn test.hex .................
Are you saying that you do this for every unit made?
Lots of people use a commercial-grade downloader software when factory-programming - so the downloader supports a script language where it can auto-generate serial numbers, MAC addresses, production week or other information and inject into the download on-the-fly. And can at the same time write an output file in CSV or similar for import into a production database for later tracking.
Per Westermark, this is exactly the approach. My way of doing this is very similar. So an application that can get characteristics from csv file, somehow generate the patch hex data code to flash to the target.
This somehow way can be intake the csv record, and in my example, generate the c file, shell out to call the compiler/linker/fromelf to get the hex and then page flash to the target.
Nevil Chapada - yes, need to characterised for every unit, as Per Westermark's example of MAC addresses and serial numbers.
I'm well aware of the requirement to individually program each unit with specific detail. I've done it myself many, many times during the past 25+ years!
What I have never considered and would never seriously consider is using the compiler to produce that specific detail. It just sounds plain wrong!
Nevil Chapada, I am talking about complicate structure of characteristics, containing numerous floating point numbers and integers. May be there is some other easy way to generate this structure of floating points intermix with integers into the correct binaries.
I am talking about complicate structure of characteristics, containing numerous floating point numbers and integers.
Can't see anything unusual about that. I've just written simple C programs or scripts to do such things and handed it to production. I don't want (and they wouldn't want) a development environment on their PCs.
"This somehow way can be intake the csv record, and in my example, generate the c file, shell out to call the compiler/linker/fromelf to get the hex and then page flash to the target."
But why, why, why involving a C compiler to compile and convert and mish and mash around the data?
You talk about "complicated structures", but haven't given a single indication that you really have anything complicated to handle.
I would not involve a compiler run once/line to convert the individual lines of a CSV file into multiple HEX files for loading. I would write one source code that would read the CSV file and directly produce the HEX output. And I would consider integrating that program directly with the factory downloader code to do the full factory programming as a single step - merge one bootloader binary + one application binary + one configuration binary formed from the CSV input data.
You don't write one calculator software to solve fact(15) and another to solve fact(27). You write a single software that takes the numeric value as input. It is only when doing something requiring extreme processing power, that you might consider doing an "on-the-fly" compilation of a configuration script into machine instructions - so for example some graphics applications might build on-the-fly a sequence of processor instructions based on input parameters, just to be able to cut the runtime speed of doing some very heavy noice processing of many thousands of frames of a movie.
In this case, you have locked down on a bad route and want to continue on that path even as the water gets deeper and deeper and fouler and fouler. Your compiler should produce one (1) version of the program per feature set - not per delivered unit. Anything that can be parametrized should be handled by configuration and not by custom source code lines. No other part of the distribution chain should require the use of any compiler.
you are right, compiler is very clever on this, and I am aware of this. You think so, but you're not. The compiler can be even cleverer than you're aware of at this point. So the compiler cannot do the clever thing that you mentioned, and is forced to address the corresponding location for the data. That method is not reliably sufficient to force the compiler's hand in that way.
Let me repeat: even though the compiler might seem capable of doing this for you, it's still the wrong tool for the job. There are two industry standard method of doing this:
1) Let production equipment actually do what you said you wanted to do: patch the hex file. Programming tools for factory floor use support that out of the box, and they're way better at it than any compiler+linker can hope to be. Setting aside all other things, they're cheaper.
2) Instead of locking yourself into the idea of changing the program image, have the device write calibration data into non-volatile memory as part of the production process, but after you've flashed the program. Instead you put those data into data flash, or a separate EEPROM, which is written during production.
Just because you currently hold those data in "compplicated data structures" doesn't mean that that's a good idea, much less a necessary property of the design.
Hans-Bernhard Broeker
I do not 100% aware of all the clever bits of the compiler, but regarding the question in concern about addressing the constant record via the absolute address pointer should be able to address the issue that you brought up earlier on. (In fact, the constant record does not even exist in the project build hex file).
Hans-Bernhard Broeker, Per Westermark:
I agreed that my way may not be the correct and efficient way, and surely there are production equipment solution to address this. I would appreciate if anyone can point me to those kinds of information that I can look into.
To convert the constant structure through csv record file into patch binary can also be done using script or creating proprietary executable to do the job. It is because the compiler comes in handy (the free mdk-lite can do the job), not to mention about changing the definition of the structure as revision evolved.
(In fact, the constant record does not even exist in the project build hex file).
Which makes any use of that data undefined behaviour. That gives compilers leeway to do whatever they want with the entire program from that point on.
I hope you did remember to make sure the memory area you keep those data in is actually forbidden for use by the compiler of the main code.
(the free mdk-lite can do the job)
Can: possibly. Is allowed to for that purpose: quite certainly no. You'll want to re-read your license about that a bit more closely.
Hans-Bernhard Broeker, you are right about the constant area.
I have set the target IROM limited to 0xF000 (from 0x800000 to 0x800F000), so that the compiler and linker will not use the area from 0x800F000 onwards.