Edited by Chris Walker, 16 May 2012 - 06:08 PM.
Updated reflash app to switch module out of bootloader mode at completion.
Early go!bus reflashing app for STM32-based modules
61 replies to this topic
Posted 16 May 2012 - 03:36 AM
One of our goals with Netduino Go was to make sure that modules could be easily reflashed via go!bus, with a "no-brick" failsafe and without the need for big (or fragile) in-application bootloaders. We've been working on flashing code for both STM32-based modules (Cortex-M0, -M3, and -M4) and (in conjunction with CW2) STM8S-based go!modules. Since several community members are working on modules, I wanted to get our first prototype STM32 reflashing app out there. This will allow you to flash up to 8 STM32-based modules in an automated fashion. You can also modify the code to add your test procedure, and flash+test the modules in one automated step. The attached app currently erases and flashes shield base modules (using the launch firmware), on socket 4. You can change the _socketNumber constant up top to change the socket #, and you can swap out the embedded BIN files for your own to reflash just about any flash files to your custom module. Please note that this is a prototype app. Before we create our first beta code, we often build a quick-and-dirty prototype to better understand what we're working with and to sort out implementation issues. The final reflashing code will probably look quite a bit different (and will be optimized, refactored, and generally not hacked together for testing) Chris P.S. We've discovered a quirk in the NETMF STM32 flash drivers which seems to intermittently affect deployment of really large apps like this one. If you run into troubles deploying this app (or another app immediately after this one), you can erase and reflash your mainboard. We're looking into it, and hope to contribute back any bugfixes to the NETMF core.
Edited by Chris Walker, 16 May 2012 - 06:08 PM.
Posted 16 May 2012 - 03:46 AM
To customize this app with your own flash files:
You can also mod the app to reflash up to 8 modules at once. To do this:
The app will automatically power down all other sockets during reflashing, will provide full flashing details in the Output window, and will turn on all LEDs to indicate when flashing is complete.
Posted 16 May 2012 - 04:00 AM
I love that the Netduino Go ecosystem is only a bit more than a month old...and modules are already getting new features. Thanks for all the fish, Fabien and Bertrand!
Posted 16 May 2012 - 07:06 AM
Hi Chris, I integrated the Touch Display firmware into the STM32Bootloader app and while it completes the module flashing procedure, the module fails to boot after that. The only way to recover the module is by flashing it again using ST's Flash Loader Demo. I modified the STM32Bootloader app so that it would disable write protection before erasing / flashing the chip but that did not fix the issue. I also changed the parity to Odd to match the ST Loader comm settings that I know work but that didn't change anything. No joy yet... Cheers, -Fabien.
Posted 16 May 2012 - 03:05 PM
Very interesting. Can you use FlashLoaderDemo to grab the full binary image of your device (both when flashed by the STM32FlashApp and when flashed by FlashLoaderDemo)? By comparing the "gold master" and the flashed version you should be able to see what's different.
In theory, as long as all the BIN files are there, at the right start addresses, and specified with the correct file lengths, it should just work...
Good diagnostics steps. In my testing, erasing and flashing was all that was necessary. Also, for what it's worth, Parity in the FlashLoaderDemo app should be _even_ and not odd.
Posted 16 May 2012 - 03:44 PM
Looks like it's bricked my Go! board - it makes me sad
So here's what I did...
- Connected the Netduino GO! to the SHieldbase (Socket 4) and then the GO! to the PC via USB.
- Opened the project and compiled/deployed to the Netduino GO!
- Lots of nice debug messages appeared and told me the world was fine and dandy.
- Ended up with all the lights on the scokets lit and a message saying Reflashing was complete.
- Hit Shift-F5 in VS (i.e. end debugging).
- Disconnected thye Netduino GO! and then reconnected to the computer - DOH!, reflashing program not erased will just start again.
- Waited until the Socket 4 LED stopped flashing and the rest of the LEDs came on.
- Opened a dummy test project in VS - intent is to just overwrite the app on the GO!
- Compile and deploy. Cannot find board.
- Restart the board (having disconnected the Shieldbase) holding down the button (I'm assuming this is still bootloader mode) and try to deploy. No luck.
- Open MFDeloy. Do the power/button thingy again and hit Ping. Nothing.
- Said a few unpleasant things.
To be or not to be = 0xFF
Posted 16 May 2012 - 03:49 PM
You write an essay and the dratted thing decides to work the next time you plug it in.
Hmmmm - this is going to be an interesting night.
To be or not to be = 0xFF
Posted 16 May 2012 - 04:24 PM
I was able to flash the shield base with success, but initially after the first time it appeared to have bricked my shield. I was getting a bunch of different errors, and unfortunately it was too late at night for me to have the frame of mind to record them. However, after my second attempt of reflashing, the shield base seems to work fine, with the exception of the previous PWM troubles. Chris did any of the PWM updates make it to this flash version or are they still to come? Thanks, Steve
Posted 16 May 2012 - 05:12 PM
Good point. When the app is done running, the board will probably still be in its bootloader. If you run another app on your mainboard (and worst case, detach and reattach the mainboard from your PC) you should be back up and running.
BTW, welcome to the Netduino community.
Posted 16 May 2012 - 05:14 PM
I'm guessing this is because it was still in bootloader mode. I should update the app to reboot the board after flashing
This is just a test to make sure the reflashing procedure is working well. The firmware version on the shield base is the same as before. Stefan has been able to take the community reports and isolate at least one PWM issue...so hopefully next week we can get that fixed and issue our first real update!
Posted 16 May 2012 - 05:15 PM
If you can repro the issue, please let me know.
Thanks for the detailed 'essay' though
Posted 16 May 2012 - 06:09 PM
I just updated the prototype reflash app to kick the module out of bootloader mode upon completion. When you deploy an app to use the module, it should boot up like normal. [crossing fingers] Chris
Posted 16 May 2012 - 06:45 PM
For the Touch Display,there's one file, starting @ 0x08000000 with a length of 84420 bytes.
I'll do a 'dump and compare' as soon as I get the chance today.
Perhaps you could use your own Touch Display module with the prototype bootloader app as a guinea pig during your tests since it's the only other STM32F2xx-based Go! module out there?
AN3155 describing the USART bootloader code sequence does say _even_ but in practice, the bootloader, as used in the Flash Loader Demo, doesn't seem to care either way, which is very odd: you'd think that the STM32 bootloader would reject packets as soon as communication starts on the GET command, if not sooner. Yet, it works perfectly with odd parity too.
I'll let you know what I discover...
Posted 16 May 2012 - 08:23 PM
I've attached a .zip containing 2 .hex dumps of the Touch Display module flash:
Before executing a download to device, I always have to disable write protection.
The download to device options are:
Hope this helps.
Posted 16 May 2012 - 08:43 PM
Picked up a hex compare util. 0x0319A0 to 0x031AF0 are different. (good) 4243443C45464748494ABF :204940004B4C4D4E4F50515253545556572A58595A203E616263643C65666768696A6B6C9D :204960006D6E6F70717273747576772A78797A203E2E2C3A3B3C27222829203F217B7D2021 :204980002326407E20253D2F5C2A2B2D5F203E373839203C343536202031323320202E30AD :2049A000F920002AFC20003EB400012C01FD000124F4F7000A0102030406070809F0004009 :2049C000FC01FC00FFF compared to (bad) 4243443C4546FFFFFFFFE5 :20494000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF77 :20496000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF57 :20498000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF37 :2049A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF17 :2049C000FFFFFFFFFFF 0x031B36 is also different(good has 41, bad has 37) Have zero clue what any of that means, but thought I'd do something.
Posted 16 May 2012 - 08:58 PM
Er, may be easier to say lines 2656 to 2661 in the files. My utilty was kinda old. Good :20492000A5FEA5FEA5FEA5FEA5FEA5FEA5FEA5FEA5FEA0006A414243443C45464748494ABF :204940004B4C4D4E4F50515253545556572A58595A203E616263643C65666768696A6B6C9D :204960006D6E6F70717273747576772A78797A203E2E2C3A3B3C27222829203F217B7D2021 :204980002326407E20253D2F5C2A2B2D5F203E373839203C343536202031323320202E30AD :2049A000F920002AFC20003EB400012C01FD000124F4F7000A0102030406070809F0004009 :2049C000FC01FC00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA Bad :20492000A5FEA5FEA5FEA5FEA5FEA5FEA5FEA5FEA5FEA0006A414243443C4546FFFFFFFFE5 :20494000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF77 :20496000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF57 :20498000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF37 :2049A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF17 :2049C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7
Posted 16 May 2012 - 09:18 PM
Is the data corruption at the end of the flash section? In the middle? If you pause the flash process at that point and look at the buffer coming from the embedded resource, is the data corrupted? At quick glance, it looks like a few bytes at the end of the dump aren't being written... At its core, the reflashing tool is just reading data from the embedded resource, writing it out to the MCU chip, and then reading back the data to verify. If something is missing, it's most likely either a math error or data corruption. We're packing up for MakerFaire right now, but if you don't have a chance to investigate any further than I can pull it up when I get back on Monday. Chris P.S. Global erase should work in the Flash Loader Demo program. If it doesn't, then do a full erase first...and then specify "no erase" on the flash...so that you make sure you're comparison two fully erased chips. I don't think that's affecting anything here...but something to keep in mind.
1 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
|This webpage is licensed under a Creative Commons Attribution-ShareAlike License.|