Netduino Plus 2 - Remove Bootloader ? - Netduino Plus 2 (and Netduino Plus 1) - Netduino Forums
   
Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Netduino Plus 2 - Remove Bootloader ?


  • Please log in to reply
13 replies to this topic

#1 jinkoyata

jinkoyata

    New Member

  • Members
  • Pip
  • 3 posts

Posted 05 April 2013 - 07:22 PM

Hello everybody !

 

I am strongly thinking of buying a Netduino Plus 2 (I am interested in STM32).

But I am wondering if it is possible to remove the bootloader easily, and if so, how to do that ?

 

I did browse different forum's threads and I think that it must be quite easy, like using a software or so...

 

By the way, that comment on adafruit brought me here

 

Thank you by advance !

 

 

Jinko

 



#2 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 06 April 2013 - 07:46 PM

I believe the stm32 bootloader resides in ROM and therefore cannot be removed. You can probably blow some kind of fuse to prevent explicit bootloader invocation if that's what you're getting at. EDIT: Maybe you mean the tinybooter? You should be able to remove it using the erase command in MFDeploy but naturally, you can then no longer deploy nor run any of your applications without reflashing to restore the tinybooter. I think tinyCLR (the "virtual machine" part of the firmware) relies on tinybooter so you need tinybooter even if you're developing your own firmware unless you're writing a non-.NETMF one because then you can do whatever you please.

#3 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 06 April 2013 - 08:08 PM

Hi Jinko, As hanzibal mentioned, the STM32 bootloader is built into the ROM of the STM32 chip itself. You can't (and don't want to) remove that. But as far as the NETMF bootloader goes...sure, you can erase that if you want :) Just use STDFU Tester and erase the board. Simple, done. If you want to come back to NETMF later, simply re-flash the board with the NETMF firmware. Schematics are on the downloads page. And Netduino Plus 2 is all open source. Plus pre-compiled binaries are up for download. Hack and enjoy as you desire. :) Chris

#4 jinkoyata

jinkoyata

    New Member

  • Members
  • Pip
  • 3 posts

Posted 06 April 2013 - 10:54 PM

Hello  all !

 

Thank for your quick answers !

 

Actually, I had to deal with few problems with bootloaders by the past, but it was on different target ( 8 bits µc - PIC).

But as you seem to say and as far as I know, STM32 bootloader and 8bits PIC or ATMEL bootloaders do not work the same way at all.

 

Anyway, I did order one, so I will see soon !

 

Thank you !

 

Jinko



#5 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 07 April 2013 - 08:09 PM

Yes, the MCUs you mentioned may be different architectures, yet the purpose of the bootloader is the same and that is basically to prepare the CPU (init clocks and such) before jumping to the entry point address of the firmware that you have uploaded to internal flash memory. Personally, I'm not very fond of the bank switching concept of PIC MCUs, but Microchip seem to be hanging on o that (maybe the PIC32 is an exception, I don't know) and I wonder when they will take the leap and implement their very first (?) ARM CPU. My guess is is that will become a question of do or die. ARM seem to have a real stronghold in the whole microcontroller industry, surely there are others but I don't know of any smartphone or tablet not using an ARM implementation of some sort, do you?

#6 jinkoyata

jinkoyata

    New Member

  • Members
  • Pip
  • 3 posts

Posted 07 April 2013 - 09:16 PM

Yes, bootloader has that purpose.

But the way it works (at least on PIC MCU, as far as I know) was source of problems.

 

Maybe an example will show you clearly what I mean, and have to deal with !

 

Well consider a system based on a Pic MCU. This system is able to be updated by sending to its UART a special Char, that triggers bootloader mode for flash.

 

Now consider that a parasite is interpreted as this special char ? Actually there was a very low probability, but it did happen to me...

The solution was to get rid of the bootloader and program once and for all the MCU over ICSP.

 

Then no more problem. Of course there was a lot of way to solve this problem (better design... or coding... ahem...).

 

But getting rid of the bootloader is interesting when you do not want any interference or unwanted behavior while the system is operating. 

In my opinion anyway (I can be wrong).

 

This is why I asked for that. I have to learn more and more on STM32 and NP2 can be intersting for that.

 

Anyway, thank you for replies and explanations !

 

Jinko 

 

PS: no I don't !



#7 Lunddahl

Lunddahl

    Advanced Member

  • Members
  • PipPipPip
  • 152 posts
  • LocationEurope, Denmark

Posted 07 April 2013 - 10:33 PM

To update the firmware of your Netduino device you will have to press the button while you apply power to the device, the Netduino will then enter DFU mode (Device Firmware Update), you will have to use a tool from ST Micro to update the firmware.

 

Personally I don't know any way to remove this feature, other than NOT making the button accessible to the end user.

 

If you do not press the button the board runs tinybooter that loads TinyCLR. TinyCLR then executes your program.

 

I don't think you can remove tinyBooter and still run TinyCLR, and without TinyCLR you will not be running any NETMF applications.

 

However you can replace tinyBooter and TinyCLR with your own application typically written in C/C++ and compiled with a tool chain supporting the MCU in the board, in that way the Netduinos does not differ much from other duinos.

 

- Ulrik Lunddahl



#8 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 07 April 2013 - 11:16 PM

Ulrik -- great points. A few more thoughts: 1. You actually can remove TinyBooter and just run TinyCLR on the board. You'll lose the ability to change network settings, download the application HEX files, etc. Shield Base works this way for instance, saving several KB that would otherwise go to TinyBooter. 2. You can also load firmware onto the board using MiniJTAG (including using a set of pogo pins on a programming jig). If you don't want to use USB. 3. There is no way to disable the end-user's ability to replace firmware on Netduino. The boards are specifically designed to be hackable, so the erase/boot options are all exposed. But that's very rarely a particularly new issue in-field...since users could also eat(*) the board, destroy the board, etc. Chris (*) do not eat Netduinos.

#9 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 09 April 2013 - 12:45 AM

So there's really no way of maybe using jtag to blow some fuse preventing bootloader invocation or firmware upload alltogether?

#10 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 10 April 2013 - 10:43 PM

Hi hanzibal,

You can program the Read Protection fuse on STM32 to disable JTAG (and flash readout access), among other things. You'd set RDP to level 2 (non-reversible). It's an option byte, IIRC.

Level 1 is less severe, and you should be able to turn that off.

See section 3.6.3 of the reference guide for more details:
http://www.st.com/st.../DM00031020.pdf

Please note that Netduino users generally should avoid writing that byte ;) You don't want to end up in a situation where you can't erase and reflash your Netduino...unless it's being used in a permanent installation.

Does that help point you in the right direction?

Chris

#11 Dave2548

Dave2548

    New Member

  • Members
  • Pip
  • 5 posts

Posted 22 April 2013 - 03:43 PM

I am new to the Netduino community and am having a problem flashing the latest code on my Netduino Plus 2. My setup is:

 

Windows 7 64 bit OS.

Visual Studio 2012

STDFU Tester Installed

SAMBIA Installed

 

I am trying to flash the firmware to 4.3 beta. The problem I see is that when I hold the Netduino Plus 2 button down and then insert the USB, the device manager shows other device with a ? and STM32 BOOTLOADER.

 

The STDFU tester program will not let me see the Netduino in the devices list. Am I missing a driver or perhaps not pointing to the correct one?

 

Dave



#12 Dave2548

Dave2548

    New Member

  • Members
  • Pip
  • 5 posts

Posted 23 April 2013 - 04:25 PM

I fixed my own problem with a bit of help from another post. I uninstalled all version of STMicroelctronics DfuSe. The STDFU Tester and DfuSe Demonstrator were uninstalled. I grabbed this version http://www.st.com/st...sw-stm32080.zip and installed.

 

I held the reset button and plugged in the USB and still no luck as the correct driver was not installed. Ug. I uninstalled the driver in question and did an update driver which I then pointed to the ST Microelectronics directory. Success, the driver installed and I was then able to Erase and flash the firmware. My setup now is as follows:

 

Windows 7 64 bit OS.

Visual Studio 2012

STDFU Tester Installed

 

Mf framework is at 4.3

Netduino SDK is at 4.3

Netduino Plus 2 firmware is at 4.3 Beta.

 

The only issues I have right now are trying to figure the correct sequence to plug and unplug the USB as I am deploying new code to not get error messsages. The other problem is that I still can't get the debugger to work. I don't think it is a VS 2012 problem as over the course of the last few days I have used VS2010 and 4.2 version of the framework which have not proved succesful with the debugger either.

 

Good news though, by using another serial port, I am able to put in debug statements and not have to rely on the debugger. I just print variables and locations to my Tera Term screen.

 

Dave



#13 ferdinan

ferdinan

    New Member

  • Members
  • Pip
  • 3 posts

Posted 01 August 2014 - 10:18 AM

After a week of putting my system temperature sensor with Netduino 2 in proper operation, and after using NET Micro Framework Tool Deploymennt several times I get the following response: 

  • Pinging ... Error: No response from device 
  • Erase ... Error: No response from device 

The PC is properly detecting the device as in the device manager on the USB section as Netduino. 

 I have trying to enter to bootloader mode by pressing the button before connecting the board to the PC. 
this means that: 

  • continue to make noise connected device and the blue LED stays always on. 
  • displays a message "windows need to install driver software controler STM32F2BOOTLOADER" and I can not find the file anywhere. 
  • in the Device Manager menu appears as the STM32F2BOOTLOADER other devices. 

seeing that this option not work have proven to steps he put into this post: 
http://wiki.netduino...ep-by-step.ashx 
but does not reset the component when I connect the +3.3 V with the gold pin. besides that when I connect the SAM-BA not the virtual COM port appears to allow  me to make  tinnybooter. 



I hope you understand my problem and you can help me. 
but I'll have to waste valuable time returning the device and Istarting the system again: (



#14 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 01 August 2014 - 10:26 PM

Hi ferdinan,

The "apply 3V3 to gold pad" procedure was for the older gen1 Netduino gear.

For your Netduino 2, you're doing it right. But you need to install the STDFU tools first (as linked from the firmware update thread). If you've done that already, then you may need to manually install the drivers for your STM32F2BOOTLAODER device.

Chris




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

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