Netduino home hardware projects downloads community

Jump to content


Photo

Early go!bus reflashing app for STM32-based modules


  • Please log in to reply
61 replies to this topic

#1 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7165 posts
  • LocationNew York, NY

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.

Attached Files


Edited by Chris Walker, 16 May 2012 - 06:08 PM.
Updated reflash app to switch module out of bootloader mode at completion.


#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7165 posts
  • LocationNew York, NY

Posted 16 May 2012 - 03:46 AM

To customize this app with your own flash files:
  • Open the BinariesToFlash.resx source file
  • Delete the 4 BIN files which are embedded there.
  • Also delete those files from the project's Resources folder.
  • Add your BIN files as resources in the BinariesToFlash.resx resource file.
  • At the top of Program.cs, modify the _flashFiles array to specify your BIN files instead. You'll need to specify a description, the resource path to your BIN file, the flash offset, and the file size.

You can also mod the app to reflash up to 8 modules at once. To do this:
  • uncomment the first two lines of the Main routine (the socketNumber loop) along with the closing bracket for that loop at the end of Main.
  • change the bootloader constructor to use 'socketNumber' instead of '_socketNumber' (removing the underscore)

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.

#3 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 16 May 2012 - 03:51 AM

Great work Chris! Thank you :) I'm going to see how I can integrate the update for the Touch Display module into it immediately. Cheers, -Fabien.

#4 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7165 posts
  • LocationNew York, NY

Posted 16 May 2012 - 04:00 AM

Great work Chris! Thank you :)

I'm going to see how I can integrate the update for the Touch Display module into it immediately.

Cool.

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!

Chris

#5 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

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.

#6 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7165 posts
  • LocationNew York, NY

Posted 16 May 2012 - 03:05 PM

Hi Fabien,

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.

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...

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.

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.

Chris

#7 jad73994

jad73994

    New Member

  • Members
  • Pip
  • 3 posts

Posted 16 May 2012 - 03:09 PM

^Same. Appears to still be in the bootloader.

#8 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 916 posts
  • LocationNorth Yorkshire, UK

Posted 16 May 2012 - 03:44 PM

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.

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.

Any ideas?

Regards,
Mark

To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life


#9 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 916 posts
  • LocationNorth Yorkshire, UK

Posted 16 May 2012 - 03:49 PM

Looks like it's bricked my Go! board - it makes me sad :(

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.

Regards,
Mark

To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life


#10 Gutworks

Gutworks

    Advanced Member

  • Members
  • PipPipPip
  • 363 posts
  • LocationOttawa, Ontario

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

#11 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7165 posts
  • LocationNew York, NY

Posted 16 May 2012 - 05:12 PM

Hi jad73994,

^Same.

Appears to still be in the bootloader.

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.

Chris

#12 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7165 posts
  • LocationNew York, NY

Posted 16 May 2012 - 05:14 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.

I'm guessing this is because it was still in bootloader mode. I should update the app to reboot the board after flashing :)

Chris did any of the PWM updates make it to this flash version or are they still to come?


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!

Chris

#13 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7165 posts
  • LocationNew York, NY

Posted 16 May 2012 - 05:15 PM

You write an essay and the dratted thing decides to work the next time you plug it in.

If you can repro the issue, please let me know.

Thanks for the detailed 'essay' though :)

Chris

#14 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7165 posts
  • LocationNew York, NY

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

#15 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 16 May 2012 - 06:45 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...


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?

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.
Chris


Right.

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...

-Fabien.

#16 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 16 May 2012 - 08:23 PM

Chris,

I've attached a .zip containing 2 .hex dumps of the Touch Display module flash:
  • The file named "NwazetDisplayModule.hex" was flashed with ST's Flash Loader Demonstrator and works as expected.
  • The file named "NwazetDisplayModuleBad.hex" was flashed with the bootloader application you provided and doesn't work as expected.
When flashing the Touch Display module using ST's tool, the target is a STM32F2_512K (PID:0411, BID:3.2,Version:3.0).

Before executing a download to device, I always have to disable write protection.

The download to device options are:
  • Erase necessary pages (Global Erase never works)
  • Address 0x08000000
  • Verify after download
I haven't analyzed the differences between the two files yet but I figured that you and David would find this useful in your own investigations.

Hope this helps.

Cheers,
-Fabien.

Attached Files



#17 NXTwoThou

NXTwoThou

    Advanced Member

  • Members
  • PipPipPip
  • 67 posts
  • LocationTulsa, OK

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.

#18 NXTwoThou

NXTwoThou

    Advanced Member

  • Members
  • PipPipPip
  • 67 posts
  • LocationTulsa, OK

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

#19 Fabien Royer

Fabien Royer

    Advanced Member

  • Members
  • PipPipPip
  • 406 posts
  • LocationRedmond, WA

Posted 16 May 2012 - 08:58 PM

Thanks Jason Posted Image

Chris,

See the attached file showing the differences that I have discovered.

Cheers,
-Fabien.

Attached Files



#20 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7165 posts
  • LocationNew York, NY

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.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2010-2014 Secret Labs LLC  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.