I am playing with STM32F4DISCOVERY kit.
I am loading a simple "blink led" program from jeremyherbert. I managed to compile the code and load it with OpenOCD. I loaded the code with the following command:
flash write_image main.bin 0x08000000
The program loads and runs after resetting the board. However, write_image command works only after I erase flash with:
flash erase_sector 0 0 11
If I do not erase flash, even if I do write_image with success, the program won't run (the leds won't blink).
Question: Why do I need to erase_sector before writing image? Why write_image alone is not enough?
Related
I have an steval-stwinkt1 board, that i am trying to enable support for DFU mode.
I flashed costume boot loader firmware on to the the start of the flash (0x8000000) that lets you load into another firmware that was uploaded by the DFU mode or to stay in the current program to flash new firmware throw the USB.
i used this st tutorial- https://www.youtube.com/watch?v=n_LDXOQHerU
I tried the .dfu package that comes with the STM32Cube and i saw that the program ran successfully so i assume that the bootloader works.
but when i try to make my own DFU package from my software the software never loads and i get hard fault. i moved the software according to the ST totorial & some research i done to 0x800C000 by changin the following lines:
in the FLASH.ld file:
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 2048K
to:
FLASH (rx) : ORIGIN = 0x800C000, LENGTH = 2048K
and in the stm32l4r9xx.h changed FLASH_BASE to:
#define FLASH_BASE (0x0800C000UL)
on another try i tried instead of changing FLASH_BASE to change VECT_TAB_OFFSET but it still didnt work.
to make the dfu package i use dfu-tool (i use linux) and use this command:
dfu-tool convert dfuse software.bin software.dfu
also tried to convert the hex int dfu package using the official tool that is used in the tutorial i used and still didnt work
what do i need to change to make my software works when i load the dfu package?
thanks
itay
It appears to me that you have overlooked the fact that your application-dedicated flash size is not going to be 2048K anymore, since your custom bootloader is now placed at the start of the flash. Therefore, you need to subtract the app's flash origin from the total flash size:
FLASH (rx) : ORIGIN = 0x800C000, LENGTH = 2048K - (ORIGIN(FLASH) - 0x8000000)
In such cases, a suggestion would be to try to debug the hard fault using the HardFault_Handler() and a bit of coding. You will then be able to extract and analyze the link register, program counter, program status register, etc. at the moment when hard fault occurred.
I'm busy bring up some new hardware with a STM32F030C8 mcu. I'm using the STM32CubeIDE with gcc. I'm very new to microcontroller development and this is my first project with ST and their tools.
This is a very basic program that just triggers a GPIO. The rest is all generated code. As I have very little experience in this field I hope somebody can point to a location where I can look. I suspect that it might be a configuration issue.
Here is the code (I removed all generated comments to keep it a bit more compact):
int main(void)
{
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_2); //my code 1
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_2); //my code 2
while (1)
{
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_2);
HAL_Delay(1000);
}
}
When I step through the code It will trigger the GPIO on "my code 1" once I step to "my code 2" it will cause the issue. I have even tried just running a fully generated program with no modifications and the issue persists. This was a quick test to see if the program actually does run on the mcu. And it does, as well as trigger the GPIO.
Debugger console Output:
Temporary breakpoint 1, main () at ../Core/Src/main.c:74
74 HAL_Init();
Program received signal SIGTRAP, Trace/breakpoint trap.
0x1fffecec in ?? ()
The Temporary breakpoint is where the program starts, I can then either run from there. Or step through, all with the same result.
Console Output:
Waiting for debugger connection...
Debugger connected
-------------------------------------------------------------------
STM32CubeProgrammer v2.4.0
-------------------------------------------------------------------
ST-LINK SN : 34FF6E065250343816210143
ST-LINK FW : V2J36S7
Voltage : 3.22V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x440
Device name : STM32F05x/F030x8
Flash size : 64 KBytes
Device type : MCU
Device CPU : Cortex-M0
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_PEkdAh.srec
File : ST-LINK_GDB_server_PEkdAh.srec
Size : 4944 Bytes
Address : 0x08000000
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 4]
Download in Progress:
File download complete
Time elapsed during download operation: 00:00:00.627
Verifying ...
Download verified successfully
Full Error:
Break at address "0x1fffecec" with no debug information available, or outside of program code.
Here is two images that might help. As I mention I'm very new to this. So any other information required please ask. Thanks in advance.
Debug View
Disassembly
The code is placed at 0x08000000. There is no user code at 0x1fffecec. It system area and probably it boots the system bootloader. It shows that the BOOTx pin is incorrectly connected.
I have compiled u-boot from u-boot-2013.01.y branch for versatilebp board (arm), and I need fatload command that is not present in this configuation.
I'm running u-boot under qemu
DRAM: 128 MiB
WARNING: Caches not enabled
Using default environment
In: serial
Out: serial
Err: serial
Net: SMC91111-0
Warning: SMC91111-0 using MAC address from net device
VersatilePB # fat
Unknown command 'fat' - try 'help'
VersatilePB # help
? - alias for 'help'
base - print or set address offset
bdinfo - print Board Info structure
bootm - boot application image from memory
bootp - boot image via network using BOOTP/TFTP protocol
cmp - memory compare
cp - memory copy
crc32 - checksum calculation
dhcp - boot image via network using DHCP/TFTP protocol
env - environment handling commands
erase - erase FLASH memory
flinfo - print FLASH memory information
go - start application at address 'addr'
help - print command description/usage
iminfo - print header information for application image
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing address)
mtest - simple RAM read/write test
mw - memory write (fill)
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
reset - Perform RESET of the CPU
setenv - set environment variables
tftpboot- boot image via network using TFTP protocol
version - print monitor, compiler and linker version
VersatilePB #
I need fatload to load file containing image of fat filesystem containing kernel of freebsd. Can I somehow change compile config for that board to compile u-boot with fatload command? Or it's just not possible/not supported for that board?
Having done more or less exactly this for a Versatile AB, it's most certainly possible. The simplest way is to find where that board's command set is defined, and hack in the commands you want by defining the relevant CONFIG_CMD_* symbols. In this case, that place is include/configs/versatile.h.
Looking at my checkout of 2015.07, I seem to have added, among others (I think I was trying to convince the MMC to work at the time), these lines:
#define CONFIG_CMD_FAT
#define CONFIG_DOS_PARTITION 1
My NodeMCU program has gone in to infinite reboot loop.
My code is functionally working but any action I try to do, e.g. file.remove("init.lua") or even just =node.heap(), it panics and reboots saying: PANIC: unprotected error in call to Lua API (not enough memory).
Because of this, I'm not able to change any code or delete init.lua to stop automatic code execution.
How do I recover?
I tried re-flashing another version of NodeMCU, but it started emitting garbage in serial port.
Then, I recalled that NodeMCU had two extra files: blank.bin and esp_init_data_default.bin.
I flashed them at 0x7E000 and 0x7C000 respectively.
They are also available as INTERNAL://BLANK and INTERNAL://DEFAULT in the NodeMCU flasher.
This booted the new NodeMCU firmware, all my files were gone and I'm out of infinite reboot loop.
Flash the following files:
0x00000.bin to 0x00000
0x10000.bin to 0x10000
And, the address for esp_init_data_default.bin depends on the size of your module's flash.
0x7c000 for 512 kB, modules like ESP-01, -03, -07 etc.
0xfc000 for 1 MB, modules like ESP8285, PSF-A85
0x1fc000 for 2 MB
0x3fc000 for 4 MB, modules like ESP-12E, NodeMCU devkit 1.0, WeMos D1 mini
Then, after flashing those binaries format its file system (run "file.format()" using ESPlorer) before flashing any other binaries.
Downloads Link
I've just finished working through a similar problem. In my case it was end-user error that caused a need to forcibly wipe init.lua, but I think both problems could be solved similarly. (For completeness, my problem was putting a far-too-short dsleep() call in init.lua, leaving the board resetting itself immediately upon starting init.lua.)
I tried flashing new NodeMCU firmware, writing blank.bin and esp_init_data_default.bin to 0x7E000 and 0x7C000, and also writing 0x00000.bin to 0x00000 and 0x10000.bin to 0x10000. None of these things helped in my case.
My hardware is an Adafruit Huzzah ESP8266 breakout (ESP-12), with 4MB of flash.
What worked for me was:
Download the NONOS SDK from Espressif (I used version 1.5.2 from http://bbs.espressif.com/viewtopic.php?f=46&t=1702).
Unzip it to get at boot_v1.2.bin, user1.1024.new.2.bin, blank.bin, and esp_init_data_default.bin (under bin/ and bin/at/).
Flash the following files to the specified memory locations:
boot_v1.2.bin to 0x00000
user1.1024.new.2.bin to 0x010000
esp_init_data_default.bin to 0xfc000
blank.bin to 0x7e000
Note about flashing:
I used esptool.py 1.2.1.
Because of the nature of my problem, I was only able to write changes to the flash when in programming mode (i.e. after booting with GPIO0 held down to GND).
I found that I needed to reset the board between each step (else invocations of esptool.py after the first would fail).
Erased the flash. esptool.py --port <your/port> erase_flash
Then I was able to write a new firmware. I used a stock nodeMCU 0.9.5 just to isolate variables, but I strongly suspect any firmware would work at this point.
The only think that worked for me was python flash tool esptool in ubuntu, windows flashtool never deleted init.lua and reboot loop.
Commands (ubuntu):
git clone https://github.com/themadinventor/esptool.git
cd esptool
python esptool.py -h
ls -l /dev/tty*
nodemcu_latest.bin can be downloaded from github or anywhere.
sudo python esptool.py -p /dev/ttyUSB0 --baud 460800 write_flash --flash_size=8m 0 nodemcu_latest.bin
I'm trying to get a stand-alone application for U-Boot running.
Target is a LEGO EV3 brick - it has an TI OMAP (ARM9) CPU.
The output of U-Boot before hanging is:
U-Boot > fatload mmc 0:1 c0007FC0 uimage
reading uimage
384 bytes read
U-Boot > bootm
## Booting kernel from Legacy Image at c0007fc0 ...
Image Name: ITK EV3 sample OS
Image Type: ARM Linux Standalone Program (uncompressed)
Data Size: 320 Bytes = 0.3 kB
Load Address: c0008000
Entry Point: c0008000
Loading Standalone Program ... OK
OK
I tried the following commands to be located at address 0xC0008000 in "uimage":
mov pc, lr (ARM code)
bx lr (ARM code)
bx lr (Thumb code)
These commands should simply return (depending on ARM or Thumb mode being active). However all three commands result in U-Boot hanging so no more output is done after the last "OK".
Why does U-Boot hang?
I found out the answer myself:
In the version of u-boot used on the EV3 brick there is a bug: The starting address that is already converted to little-endian is converted twice so the result is - of course - wrong.
By storing the number little endian in the file the output of u-boot will be wrong:
Image Type: ARM Linux Standalone Program (uncompressed)
Data Size: 320 Bytes = 0.3 kB
Load Address: c0008000
Entry Point: 008000c0 <--- actually 0xC0008000!!!
Loading Standalone Program ... OK
OK
U-Boot >
however booting will work. This bug only affects stand-alone programs and not Linux kernels.
My problem is that the program will possibly be published so it must work with both buggy and bug-fixed u-boot versions.
Therefore I think about loading the program to an address like
0xC00101C0
which is stored little and big endian the same way.