Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Maintain Microprocessor (STM32F7) Code After Power Off

Status
Not open for further replies.
U

uranyumx

Advanced Member level 4
Full Member level 1
Joined
Mar 5, 2011
Messages
102
Helped
1
Reputation
2
Reaction score
0
Trophy points
1,296
Activity points
2,098
Hello,

I developed a custom-designed system with an STM32F767 microprocessor and controlled its parameters with a user interface through a Bluetooth module. When I power off then power on the system, I couldn't communicate with the circuit board. Is there a way to store data without affecting power off?

Edit:
Is there a way to store codes without affecting power off?

Thank you,
 
Last edited:

Sort by date Sort by votes
Hi,

I´m confused.

Headline talks about CODE, but
text talks about DATA.

When you write code into the FLASH it will survive power down.
When you write code intom the SRAM it will be lost after power down.

Power OFF affects (clears) data in SRAM, but
data won´t affect power down. (as you write)

Klaus
 

Upvote 0 Downvote
Ok, this is my mistake. I edited the first thread.

How can I write or migrate the codes to the FLASH? @KlausST
 

Upvote 0 Downvote
Is there not APIs in the IDE library to write FLASH under program control to emulate EEPROM ?

Not a ST expert here, just that is a pretty common feature these days on embedded parts.
Basically set up a structure that holds data to be saved and upon power/brown out detection
write the FLASH where you have mapped a section using pointers. Note you use a cap to hold
up processor long enough to get this done on power loss detection. What ever that criteria is.



Regards, Dana.
 

Upvote 0 Downvote
I set the pin and clock configuration in STMCubeMX toolchain and programmed in Keil uVision IDE.
 

Upvote 0 Downvote
Hello @KlausST ,

Now I am using the CubeIDE, so how I write the codes in the FLASH memory? Should I write only the variables or main code sections as well?
 

Upvote 0 Downvote
Hello!

how I write the codes in the FLASH memory?
Click to expand...

I didn't read the whole link, but apparently it explains how to do. And there is some source code.

Should I write only the variables or main code sections as well?
Click to expand...

I'm not sure of what you are asking. Usually when you have some variables you want to store
after setup, you just store these variables, and not more.
Let's take an example. You make a signal generator, and you want it to remember the frequency
you last set. Let's assume this frequency is a uint32 (4 bytes), then you have to write only these 4
bytes into the flash.
What do you mean by main code sections?

Dora.
 

Upvote 0 Downvote
I've had a quick look at the data sheet for that MCU but I wouldn't see it clearly stated but....
While many MCUs allow you to write small data sizes to FLASH, many will have a lower limit on the erase page size. Also you generally need to erase the section of memory before you write to it.
Therefore you may need to use the 'read a page - update the bytes you want - erase the page - write the page' approach.
Also watch out for the maximum number of erase/write cycles that the FLASH memory can endure. If you try to update the FLASH memory fairly often (in the order of seconds) then you can start to get errors creeping in after a few months/years.
If you have the Vbat available to you when you drop the Vcc, then that MCU has some SRAM that could be used.
Often it is easier to use some external EEPROM (or FRAM or similar) and use that to save variables.
Susan
 

Upvote 0 Downvote
Storing non-volatile data in flash memory is o.k. if they are written infrequently (e.g. less than 1/day) so you don't run at risk to reach maximal flash cycles.
 

Upvote 0 Downvote
Thank you for your answers @danadakk , @FvM , @doraemon , and @Aussie Susan !

Basically, my system is rechargeable battery-powered. When the battery is discharged and the system goes power off, I don't want to debug again the system after charging the battery. Doing this purpose, I learned that the FLASH memory needs to use instead of RAM based on your comments and other readings from the ST community. To store in the FLASH memory, BOOT0 pin was connected to the GND through a 10 kOhm resistor. I didn't do any other configuration rather than that. Then, I run the code and press 'Release' at an hammer icon in the CudeIDE. In the memory regions menu, I saw that 8.01% percent used the Flash memory. But I still cannot run the system after power off. Should I try EEPROM?

Attached files: CubeProgrammer schreenshots of the OB menu.
--- Updated ---

In addititon, after flashing codes to the microprocessor, I powered off and on while the ST link adapter connected. In that case, the system works. When I remove the adapter and powered off and on, the processor needs to flash the codes.
 

Attachments

  • Debug1.PNG
    Debug1.PNG
    129.1 KB · Views: 132
  • Debug2.PNG
    Debug2.PNG
    126.5 KB · Views: 139
Last edited:

Upvote 0 Downvote
I get the impression that we have moved to another problem here - are you saying that your CODE is not being programmed into the Flash memory???
I understand that you are using the CubeIDE for the development but what is your programmer and is the board one of your own or are you using something like a Nucleo board?
What should be happening is that you use the programmer (or the one built in to the Nucleo (or whatever) board) to send your code to the Flash memory. Thew whole point of the Flash memory is that it WILL hold the code over a power cycle.
I am a little concerned about your reference to BOOT0 as that is used to send the MCU into the bootloader on power reset and I don't think that is what you want to do. (However it does make me think that you are using your own board and possibly an external programmer).
I think we need a full description of your development environment and all of the steps you are taking to program the board. I suspect that you are diving unnecessarily into some areas that are for very advanced and specialised uses only.
Susan
 

Upvote 0 Downvote
Hi,

I also guess there is a lot of misunderstanding ... or using phrases the wrong way.
Just going through post#13:
* "debugging" ... means: finding errors
--> what you probably mean is "uploading". This is when the PC moves the executable CODE to the microcontroller
* CODE (in the meaning of "program") is the executable part generated by the compiler. It contains the instructions. Not specifying the language. Code has different meanings.
* SOURCECODE usually is the input for a compiler/assembler
* DATA is non executable code, like constants, table contents, variables
* FLASH is a nonvolatile memory for data and/or code. Keeps informations during power down
* SRAM is volatile memory. Used for variables during processing. Some microcontrollers even may store/execute CODE (instructions) from SRAM.
Usually small microcontrollers use Harvard architecture where executable code is placed in FLASH only and executed from Flash.
Processors (PC) use von neumann architecture, where code is executed from SRAM.
STM32 microcontrollers use ARM technology, which usually is Harvard architecture. Thus it depends on the chip you use whether the program can be executed from program-SRAM or not. For STM32 usually the program is downloaded into FLASH and executed from FLASH.
* EEPROM is non volatile data memory with high write cycle endurance. If I'm not mistaken, then STM32 microcontrollers don't have internal EEPROM at all. Please check datasheet on this.

* BOOT0 pin(combined with Boot1) does not determine where the program is stored to, it determines where the code is executed from.
1) user-flash: If you want execute code from FLASH you first need to upload the code into user-flash.
2) system-flash: usually the STM bootloader is stored in system-flash.
3) If you want to execute the code from SRAM then you first need to download the code into SRAM. (unusual)
Thus indeed BOOT0 usually determines whether - after Reset - your code is executed or the bootloader

Are you sure that your code is not kept during power loss? How exactly did you test it?

Klaus
 

Upvote 0 Downvote
Thank you @Aussie Susan and @KlausST for your clear comments.

@Aussie Susan
I have a custom-designed PCB and uses an STM32F767 microprocessor. For uploading the executable codes to the microprocessor, I use an ST-Link adapter. According to the IDE screenshot (attached), the codes are stored in the FLASH memory of the microprocessor; however, after power off and cycles, I couldn't use the board so I suspect that whether the executable codes were not properly stored or the stored data graph on the screenshot has standard parameters. I have lots of peripherals and Bluetooth control on the PCB so I don't know how the Nucleo board can be used.

@KlausST
Thank you for the clarification on the parameters! I have a custom user interface (Matlab GUI) to control the parameter values in the microprocessor via Bluetooth. I hit the 'Run' (Green play button on CubeIDE and selected 'Release' at the 'hammer' icon) button to upload the executable codes (attached is the report that I got from the 'console' at the cubeIDE). Then, I make a Bluetooth connection between the interface (PC) and Bluetooth on the PCB. After that I test it, then it works (transmits set values of the interface and received converted analog signals). Next, I disconnect the Bluetooth with a button on the interface. Then, I physically disconnect/remove the ST-Link adapter. Then, I make a Bluetooth connection between the interface (PC) and Bluetooth on the PCB. After that I test it, then it works. Last, I powered off and on the PCB. Then, I make a Bluetooth connection between the interface (PC) and Bluetooth on the PCB (without the ST link adapter). After that, I didn't observe transmission (checking with the oscilloscope whether any signals are generating) and receiving (on the interface screen). In addition, on the power supply screen, the initial current consumption was 90 mA, then it decreased gradually to 55 mA after power was off and on.

On the other hand, while the ST-Link adapter was connecting to the PCB debugger connector, the system worked after powered off and on. Thus, the system operation is depending on the ST link adapter connection.
 

Attachments

  • Debug1_1.PNG
    Debug1_1.PNG
    8 KB · Views: 117
  • Console report.txt
    1.6 KB · Views: 135

Upvote 0 Downvote
If you have 'hard wired' the BOOTn pin(s) then you are probably still trying to go to the bootloader on power up instead of your code.
Are you using the JTAG or SWD with the ST-Link to program/debug your program?
Have you used the recommended circuit to connect to the STM32 MCU? (The ones that I've seen have the BOOT0 pin connected to ground and just use the SWDIO, SWCLK and NRST signals from the ST-Link programmer.)
Susan
 

Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top