stm32sleep
stm32sleep copied to clipboard
Freeze/hang when flashed without the bootloader
Does this library mandate using the STM32Duino bootloader? Or is there some implicit dependency?
I have a project where I'm going into standby and waking up on the WKUP pin going high. On wake up, I'm checking the PWR_CSR register for wake up reason using
unsigned int wokeupFromSleep() {
return PWR_BASE->CSR & PWR_CSR_WUF;
}
IN any case, the entire thing works flawlessly as long as I have stm32duino flashed. The only issue is that this takes up additional time on every wake up. So I flashed the same program via STLINK and now whenever the code encounters either wokeupFromSleep or goToSleep(STANDBY), it just hangs (serial freezes, PC13 remains ON etc).
Any ideas what might be causing that?
Did you recompile the program to start at 0x08000000?
Il giorno sab 15 giu 2019 alle 19:40 Raghu [email protected] ha scritto:
Does this library mandate using the STM32Duino bootloader? Or is there some implicit dependency?
I have a project where I'm going into standby and waking up on the WKUP pin going high. On wake up, I'm checking the PWR_CSR register for wake up reason using
unsigned int wokeupFromSleep() { return PWR_BASE->CSR & PWR_CSR_WUF; }
IN any case, the entire thing works flawlessly as long as I have stm32duino flashed. The only issue is that this takes up additional time on every wake up. So I flashed the same program via STLINK and now whenever the code encounters either wokeupFromSleep or goToSleep(STANDBY), it just hangs (serial freezes, PC13 remains ON etc).
Any ideas what might be causing that?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/chacal/stm32sleep/issues/7?email_source=notifications&email_token=AE2NS3UZAILJ5LO5JNUEFR3P2USSLA5CNFSM4HYPQBW2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GZWRV5A, or mute the thread https://github.com/notifications/unsubscribe-auth/AE2NS3T5VMVSVGJVNDVFRDLP2USSLANCNFSM4HYPQBWQ .
Once I change the upload method to STLINK and upload with VS code, it seems to start writing at 0x8000000. Is there anywhere else I need to change? Output from flash
Sketch uses 21876 bytes (33%) of program storage space. Maximum is 65536 bytes.
Global variables use 3296 bytes (16%) of dynamic memory, leaving 17184 bytes for local variables. Maximum is 20480 bytes.
Uploading...
2019-06-15T23:01:47 INFO src/stlink-usb.c: -- exit_dfu_mode
2019-06-15T23:01:47 INFO src/stlink-common.c: Loading device parameters....
2019-06-15T23:01:47 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-06-15T23:01:47 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2019-06-15T23:01:47 INFO src/stlink-common.c: Attempting to write 21876 (0x5574) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
Flash page at addr: 0x08000400 erased
Flash page at addr: 0x08000800 erased
Flash page at addr: 0x08000c00 erased
Flash page at addr: 0x08001000 erased
Flash page at addr: 0x08001400 erased
Flash page at addr: 0x08001800 erased
Flash page at addr: 0x08001c00 erased
Flash page at addr: 0x08002000 erased
Flash page at addr: 0x08002400 erased
Flash page at addr: 0x08002800 erased
Flash page at addr: 0x08002c00 erased
Flash page at addr: 0x08003000 erased
Flash page at addr: 0x08003400 erased
Flash page at addr: 0x08003800 erased
Flash page at addr: 0x08003c00 erased
Flash page at addr: 0x08004000 erased
Flash page at addr: 0x08004400 erased
Flash page at addr: 0x08004800 erased2019-06-15T23:01:48 INFO src/stlink-common.c: Finished erasing 22 pages of 1024 (0x400) bytes
2019-06-15T23:01:48 INFO src/stlink-common.c: Starting Flash write for VL/F0/F3 core id
2019-06-15T23:01:48 INFO src/stlink-common.c: Successfully loaded flash loader in sram
Flash page at addr: 0x08004c00 erased
Flash page at addr: 0x08005000 erased
Flash page at addr: 0x08005400 erased
0/21 pages written
1/21 pages written
2/21 pages written
3/21 pages written
4/21 pages written
5/21 pages written
6/21 pages written
7/21 pages written
8/21 pages written
9/21 pages written
10/21 pages written
11/21 pages written
12/21 pages written
13/21 pages written
14/21 pages written
15/21 pages written
16/21 pages written
17/21 pages written
18/21 pages written
19/21 pages written
20/21 pages written2019-06-15T23:01:49 INFO src/stlink-common.c: Starting verification of write complete
21/21 pages written2019-06-15T23:01:49 INFO src/stlink-common.c: Flash written and verified! jolly good!
The issue remains, but a viable alternative is to use the FASTBOOT bootloader. Flashing the fastboot bootloader is a pain though currently - see here
I'm still interested in why a bare flash doesn't work as expected.
Try posting to the stm32duino.com forum for support.
Il giorno dom 16 giu 2019 alle 15:45 Raghu [email protected] ha scritto:
The issue remains, but a viable alternative is to use the FASTBOOT bootloader https://www.stm32duino.com/viewtopic.php?t=4401. Flashing the fastboot bootloader is a pain though currently - see here https://github.com/rogerclarkmelbourne/STM32duino-bootloader/issues/69#issuecomment-502422037
I'm still interested in why a bare flash doesn't work as expected.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/chacal/stm32sleep/issues/7?email_source=notifications&email_token=AE2NS3S254QKYJV3OBDKW5DP2Y7W7A5CNFSM4HYPQBW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXZNMEA#issuecomment-502453776, or mute the thread https://github.com/notifications/unsubscribe-auth/AE2NS3XB7NAODVNXSS3BESLP2Y7W7ANCNFSM4HYPQBWQ .