Its been a while since I've been on the Keil forums. Not exactly a fan of this new ARM forum format... yet. I am doing a project using a STM32L4xx MCU. While my PCB is out to fab, I will be writing the bring-up firmware. I purchased the STM32L476G-EVAL demo board to test my code-monkey code which will be re-targeted for the actual MCU/PCB. Since the EVAL has some spiffy pre-loaded firmware already in it, I'd like to read the existing code, save it, and then flash it back when I'm done. (I also downloaded the official Eval firmware .hex file from ST-Micro's website). Usually, I write the bring-up code on the actual target PCB/Assembly, but this time, I've purchased a dev board (I rarely ever do that). I usually don't need to read/write the flash independently from the source code, hence this stupid question. Lurking through the Keil 'documentation' it isn't clear what the steps are to 1) Read MCU Flash into a file 2) Write an existing .hex file into the MCU Flash I want to do this as simply as possible. Our company purchased a ULINK2 and Eval Board and is sticking with the Keil Evaluation MDK until I scream about it. I don't think I'll need 32K for this project. Then, after the prototype works out, we will buy the real deal MDK. Also, "Hi" to all those old-timer Keil contributors... I won't list them (e.g. Andy, or Per, Erik, etc.) because I might offend those I don't mention. (Obviously, its me---long winded question) --Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Keil doesn't provide the easiest of methods to extract the firmware. The debugger has a SAVE command, and if the external memory interfaces are up you can pull from QSPI/NOR devices.
For the STM32 boards, the best route is to use the ST-LINK Utilities or STM32 Cube Programmer, the CLI variant of the former being preferable. Where external memories are involved an External Loader should be specified. The EVAL board should have one. Any way, either of these tools should be able to save a .BIN or .HEX for the preshipped firmware on the devices, and associated external memories.
Thanks Pier! Glad to see your response. I shall purchase both flavors 1) ST-LINK/V2 in-circuit debugger/programmer for STM8 and STM32 ($21) 2) STLINK-V3 modular in-circuit debugger and programmer for STM32/STM ($35) STLINK-V3 has the CLI and could also be used by the techies after I'm done with them. I can use the ST-LINK/V2 for playing with the EVAL board. (Then ULINK2 for the real PCB) Thanks again for the prompt reply.
The EVAL board should have an ST-LINK built into it.
Westonsupermare Pier said:For the STM32 boards, the best route is to use the ST-LINK Utilities
But why bother?
Surely, ST provide the Hex (and the source?) of the original demo ?
For boards with no ST-Link on-board:www.keil.com/.../3262.htm
That should work through any debug probe?
Pier, Thanks for going the extra mile and checking the eval board specs. I'm still reading through the many .PDFsAndy, Good to see you chiming in. Its been awhile since I've been on."Surely, ST provide the Hex (and the source?) of the original demo ?" -- AndyI know they provide the .hex file: I downloaded it. Not sure if I want to spend the time to search for the source... other than looking at how they did things.Since I have such heavy hitters responding (Andy/Pier), I would like your opinion on a decision I need to make today/tomorrow.There is a time-crunch on a prototype. Its simple: peripherals read, then transmitted out, then sleep, wake, rinse-repeat.I normally do the codemonkeying from scratch (my own HALs), but for doing this time-crunch prototype for a dog-n-pony, I tried using the STM32CubeMX thing. (CubeMX is great for pin/peripheral assignments when designing the electronics system, but I've never done the Generate Code stuff and used it)Dealing with the 'source' code output of STM32CubeMX kind of blows since I am unfamiliar with it.No RTOS needed for this. Its a simple main-loop orchestrating the data with ISR driven data collection and transports.Should I spend the time ramping up on the Kid Approved STM32CubeMX interface with the Keil MDK project build, or just write it from scratch?
I am used to implementing full ISR driven architectures with my own HALs, and a main loop consisting of while( FOREVER ) DO_NOTHING; but this is too simple and time-crunched to do that for this project.The dog-n-pony is a proof of concept. I'll do it up properly after the corporate dog-n-pony show.Essentially, what I'm asking is if Andy and/or Peir--or other professionals--ever use the STM32CubeMX framework and how easy it is to use?
I'd like a serious embedded engineering perspective, not the "I just graduated from Arduino U" types.I have 7 weeks to get core technology's firmware done for the Big Reveal show.My fully assembled electronics will be back in 3-4 weeks.I just don't want to spend a week learning the STM32CubeMX generated code architecture if its a waste of time or will not be productive.The main's pseudo-code for this simple project:
The main's pseudo-code for the simple project:
Init_Core( ); // Core MCU Initialization
Init_System( ); // Non-MCU system Initialization
; Determine which UART interfaced High-Speed comm-link peripheral ;
; to use: Hardware PCB jumpers, and non-Volatile configs. ;
stream_channel = Get_System_High_Speed_Stream( );
Init_Stream( stream_channel ); // baud/etc. and Stream Device related Initialization
Check_Do_Testing_Modes( ); // Factory QA Testing configurations, etc. (stubbed for future dev)
Check_Do_Special_Modes( ); // Installation, User Testing, etc. (stubbed for future dev)
while( FOREVER ) // All error handling shall be within the functions: on-entry/on-exit
Wakeup( ); // Configure "RUN Mode" MCU state (RTC Alarm 1 or Alarm 2 wakes MCU)
Drink_Coffee( ); // Enable the non-MCU circuitry to get ready for a massive data-dump
; Read and peripheral data into a FIFO'd Data-Store buffer ;
; - (I2C x3) + (UART x1) + (MCU ADC x2) + (SPI x1) + (FPGA) ;
; - Kick-off ISR collection processes ;
; - ISRs stuffs data into FIFO'd Data Stores: flags when done ;
; - Safety Timers/Time-Outs (2x Timers) ;
Collect_Data( ); // The bulk of firmware development, besides the comm protocols
if( Flag_Upload_The_Data != FALSE ) // RTC Alarm 2 sets flag for packet uploads
Flag_Upload_Data = FALSE; // Checked\Clear flag
Format_Protocol_Packets( ); // Use Data-Store FIFO for packet content
Transfer_Upstream( stream_channel ); // Xmit/rcv packeted data upstream until done
Check_For_Commands( ); // Did they ask for anything? (Validate them)
if( Flag_Any_Commands != FALSE )
Flag_Any_Commands = FALSE; // Checked\Clear flag
Implement_Commands( ); // Alarm settings, controls, commit Human Rights crimes, detonate, etc.
Clear_Data_Store_FIFOs( ); // Should be cleaned-out due to Upload, but force FIFO maintenance anyway
Take_Valium( ); // Relax the non-MCU related circuit states for sleeping
Read_Bedtime_Story( ); // Prep the MCU for sleeping
Sleep_System( ); // Sleep until RTC Alarm 1 or 2
Its good to be writing firmware again... lots of [analog/FPGA] electronics work lately.Has Eric been around? He is another heavy-hitter in the embedded world.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Not really a Keil question, but ...
I've never really used Cube in a Real Project from scratch.
But I do have an inherited Project here that was started with Cube.
TBH, if you're OK with the STM32 and writing your own code for it, I don't see a great advantage.
I guess one place it does help is to pull everything together for the features you are using:
The trouble with STM32 (like most other Cortex-based things) is that you not only have to set-up the peripheral itself (eg, UART) but you also have to remember to set up clocks, interrupts, GPIO, DMA, etc, etc, ...
View all questions in Keil forum