Closed jacmet closed 7 years ago
Does this work ok after a reboot as well as on first boot? I did briefly play with changing the baud rate when I first started writing rBoot but had trouble getting it to work properly so gave up and just lived with it! Would be nice to have it working though, but I have no test system at the moment so can't play with it myself right now so please let me know if it's fully tested and I'll merge the PR.
It definately works after a reboot (you do get the garbage from the 1st level bootloader, and using something like RBOOT_DELAY_MICROS=100 to give it a bit of time before serial might be a good idea). My esp8266 boards are all USB powered / with USB<>serial, so it is a bit tricky to verify cold boot output.
FYI, with reboot I mean pressing the reset button, E.G. asserting the reset pin. I haven't tried doing a soft reboot. What is the API for that? system_upgrade_reboot() doesn't seem to do anything here.
Thanks. Try the standard api system_restart();
in your application and check the output is ok, if so I'll merge.
No, system_restart() doesn't seem to reset the PLL configuration, so after system_restart() I see the 1st level bootloader messages at 115200 bps, but the rboot messages are wrong (as we program the divider assuming a 52MHz APB instead of 80MHz).
I'm not sure there's any easy way of fixing that. Either through detecting the APB clock speed, configuring it ourselves or detecting the reset reason (and assuming 80MHz for soft reset).
What do you say?
The last option seems the easiest one to me, E.G. read RTC memory @ 0 and skip baudrate config on reason = 4 (REASON_SOFT_RESTART).
Rboot already has the infrastructure to read RTC memory, but I see that you disallow access to the first 64 bytes. Why is that? Did you mean to only disallow WRITES to the system area?
I only intended people to access the user area, not the system area of the rtc. This is starting to look messy, and as the rBoot messages are only needed for debugging the boot / ota process I don't think it's worth the hassle and code. Once the device is up and running a software reset (as you'd get after an ota) will show the messages at the same baud rate as the application was using before reset. When I'm debugging I always start with a software reset after first power on, then view the rBoot messages on the second and subsequent boots at full rate as set by the app.
I've now updated the patch to detect soft resets and skip the baudrate config for those. I've also verified that the baudrate config is needed for correct serial output for RTC (deep sleep) resets.
@raburton so what do you say? Any comments? Yes/No?
Thanks, looks good.
It is handy to be able to see the messages from rboot at a sensible baudrate, so add an option to configure the uart divisor.
Notice that the APB is running at 52MHz in rboot instead of the normal 80MHz in user applications.