1
preenfm2 and preenfm3 / Re: Stm32F4Discovery port
« on: July 25, 2020, 09:47:18 PM »
Hi
got another more tolerant display : a LCD this time (a 2004A).
got a 2GB USB drive,
I tries with a recompiled fw 2.11, with the 2.08 that is with the sources, tried both normal and overclocked.
I use the Linux Debian 64 St-link tools for that purpose. Has anyone go positive or negative experience to share ?
I checked again a good 3 times all connections...
Nothing seems to work :-(
Any help is welcome
EDIT
beyond likely USB key issues, I realize noting boots if I do not connect the mini USB CN1 to a computer, tested with other demo firmware.
Some people complain that depending on the ST-Link firmware, you may experience that issue... I checked the ST application for that, you do not have the choice of the ST Link firmware version, the one the application offers to upgrade to does not resolve the issue.
EDIT 2 Rebuilt a USB key, tried on crazy thing by error : re-flashed whilst on the motherboard and oh miracle: it boots, displays ...
HOWEVER : after that success: I just power it and ... nothing happens ...
@Norbim: had you to tweak anything on the BOOT0 and BOOT1 to start it ?
Do you know what ST-Link version your board has ?
I found numerous messages about recent versions of ST-Link causing that ... :-(
EDIT 3 Researching further, I found
Now debugging -- I needed a bootloader that compiles, as I was about to try and fix it, I remarked Xavier has issued one in 2.12-B3.
So far it seems trapped in a loop -- not sure why -- possibly because it does not look at the buttons where they are for the discovery board ? I dig deeper.
EDIT 4
Following up debugging -- admittedly not 1.11 bootloader but in that case, the difference seems minimal.
What happens :
in BootLoader.cpp, after construction of the object bootLoader in main, the test in line
Once again, not exact same bootloader but a refactored one, however the logics remains.
Where does bootLoader.button get changed ?
In the bootLoader constructor, it is set to 0 but , at the end, a call to "encoders.checkSimpleStatus();" somehow sets it to 8.
I am unsure the cause is the same on bl 1.11 & app 2.11 but that is my only way to try and resolve my problem.
I continue digging and maybe will attempt to port back this version of the bootLoader to the PreenFM on Discovery board so that buttons are read properly.
@Norbim: if ever you are working at porting the whole thing to 2.12 Beta3, please let me know in case I can help or you have done it already.
EDIT 5 EURÊKA ! The situation I found debugging the 2.12 B3 bootloader could well be what I had on 1.11. I checked and the bootloader I found in git is the same as the standard preenFm2. Searching attachments in this forum thread, I found the right one, all works !!
I will try and port 21.12 Beta nonetheless, just for fun.
Regards
Dominique
got another more tolerant display : a LCD this time (a 2004A).
got a 2GB USB drive,
- formatted it FAT12 with windows, --> does not work
- Formatted it FAT 16 with Linux , does not work either
I tries with a recompiled fw 2.11, with the 2.08 that is with the sources, tried both normal and overclocked.
I use the Linux Debian 64 St-link tools for that purpose. Has anyone go positive or negative experience to share ?
I checked again a good 3 times all connections...
Nothing seems to work :-(
Any help is welcome
EDIT
beyond likely USB key issues, I realize noting boots if I do not connect the mini USB CN1 to a computer, tested with other demo firmware.
Some people complain that depending on the ST-Link firmware, you may experience that issue... I checked the ST application for that, you do not have the choice of the ST Link firmware version, the one the application offers to upgrade to does not resolve the issue.
EDIT 2 Rebuilt a USB key, tried on crazy thing by error : re-flashed whilst on the motherboard and oh miracle: it boots, displays ...
HOWEVER : after that success: I just power it and ... nothing happens ...
@Norbim: had you to tweak anything on the BOOT0 and BOOT1 to start it ?
Do you know what ST-Link version your board has ?
I found numerous messages about recent versions of ST-Link causing that ... :-(
EDIT 3 Researching further, I found
- if I flash the bootloader, then nothing
- if I flash the app then OK, I assume st-link then resets from the app address ... maybe ...
Now debugging -- I needed a bootloader that compiles, as I was about to try and fix it, I remarked Xavier has issued one in 2.12-B3.
So far it seems trapped in a loop -- not sure why -- possibly because it does not look at the buttons where they are for the discovery board ? I dig deeper.
EDIT 4
Following up debugging -- admittedly not 1.11 bootloader but in that case, the difference seems minimal.
What happens :
in BootLoader.cpp, after construction of the object bootLoader in main, the test in line
- if (bootLoader.getButton() == 0 && (*(__IO uint32_t*)magicRam != BOOTLOADER_WORD)) {
Once again, not exact same bootloader but a refactored one, however the logics remains.
Where does bootLoader.button get changed ?
In the bootLoader constructor, it is set to 0 but , at the end, a call to "encoders.checkSimpleStatus();" somehow sets it to 8.
I am unsure the cause is the same on bl 1.11 & app 2.11 but that is my only way to try and resolve my problem.
I continue digging and maybe will attempt to port back this version of the bootLoader to the PreenFM on Discovery board so that buttons are read properly.
@Norbim: if ever you are working at porting the whole thing to 2.12 Beta3, please let me know in case I can help or you have done it already.
EDIT 5 EURÊKA ! The situation I found debugging the 2.12 B3 bootloader could well be what I had on 1.11. I checked and the bootloader I found in git is the same as the standard preenFm2. Searching attachments in this forum thread, I found the right one, all works !!
I will try and port 21.12 Beta nonetheless, just for fun.
Regards
Dominique