Reseting to "Factory Defaults"

LeafLabs Garden » Support » Maple Hardware Support

Reseting to "Factory Defaults"

(10 posts) (5 voices)

Started 5 years ago by DaemonMaker
Latest reply from mbolivar

DaemonMaker
Member

Hello all:

I am the proud new owner of a Leaf Maple. I've been very impressed by this project. Earlier today I grabbed a copy of the i2c branch of libmaple in hopes to contribute a little. Unfortunately I made a mistake that prevented me from uploading programs! To correct the problem I soldered on a JTAG header and flashed the chip. This left me without the ability to upload from the Maple IDE so I grabbed a copy of maple-bootloader and flashed the chip again. Now when I try to upload a program via the Maple IDE I see the following output:

error resetting after download: usb_reset(ResetDevice): no connection to an IOService state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present Done! Resetting USB to switch back to runtime mode Going to build using 'make' (ARM) Compiling core... Compiling any libs... Compiling the sketch... running linker asynchronously... running obj copy asynchronously... running size asynchronously...
/var/folders/iJ/iJPtq4QNETugjvzFG94Jrk+++TI/-Tmp-/build4734736371581637589.tmp/Blink.cpp.bin : section size addr .data 12360 0 Total 12360 Binary sketch size is reported above. Check it against a 17000 byte maximum. Loading via dfu-util Resetting to bootloader via DTR pulse Reset via USB Serial Failed! Did you select the serial right serial port? Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
Searching for DFU device [1EAF:0003]...

The IDE pauses on this last line. If I push reset during the pause then it will find the board and upload the program otherwise it will fail.

Thus far I've not been able to determine how to correct this issue. Is there documentation that outlines the proper method of returning the board to factory condition firmware-wise?

TIA,
Dustin

Posted 5 years ago #
poslathian
LeafLabs

Dustin,
If you push reset, then you can succesfully upload a program? If so, upload a program - from the IDE - into FLASH. I think what is happening is this.

- The bootloader only runs momentarily after reset, and then jumps to user code. If no user code is preset is will idle in the bootloader. If user code is present in RAM it will jump there. Finally it will jump to flash if there user code there. The check for user code is naiive, and user binaries are not CRC checked or verified, it does happen (rarely) that corrupted user binaries are uploaded.

- When you program the board from the IDE, the reset is initiated via a command over the serial port. This little auto-reset daemon is actually compiled in as part of your user code. Thus for auto-reset to work, you must
A) be running valid user code that contains the auto-reset daemon
B) have the serial port selected in the IDE menu, or have whatever command line tools properly configured.

I am not sure if this is exactly your problem, but perhaps some of it makes sense? Can you give some more details?

Posted 5 years ago #
DaemonMaker
Member

Poslathian:

Unfortunately this didn't work.

Just to be clear, I can only upload code if I push reset [em]while[/em] the IDE is trying to upload.

I suspect I used the wrong git branch. The last thing I did was clone http://github.com/leaflabs/libmaple.git and http://github.com/leaflabs/maple-bootloader.git. I then compiled the bootloader and uploaded it. Finally I compiled and uploaded the blinky example. From there I tried the IDE and encountered the error described above.

I use Ubuntu to compile and upload code from git but I use the IDE under OSX. Before I changed the firmware there was no problem. I'm using v00018 of the IDE and I'm using the CodeSourcery EABI tool chain under Linux.

I'm not sure if this is the detail you were looking for so please feel free to point out something I may have missed.

Dustin

Posted 5 years ago #
poslathian
LeafLabs

It is strange that it worked before but not after uploading the fresh bootloader. The version you got from git is the correct version.

As you have described things, your bootloader is functioning properly. If you hit reset and you successfully upload code, then the bootloader did its job. After reset it came up, enumerated itself to your computer, and ate code over dfu from the IDE and ran it (i assume it ran it...is it running blinky?).

The problem is that when you try and upload more code, the board does not reset by itself, like its supposed to. The auto-reset feature is a function of the user code - hidden inside libmaple. Can you verify some things for me:
1) when your board is running blinky does the Maple Serial port exist? (does SerialUSB.print work, or does the device come up in whatever listing your OS provides? I think in mac it should come up as a modem device labeled Maple Virtual COM)
2) if you use permanent bootloader mode, are you successful? To do this, hit reset immediately followed by pressing and holding the secondary button labeled BUT. You should notice that the bootloader transitions from quick blinks to slow blinks after reset, the idea is to have the BUT button held down when this transition occurs. The LED should now blink slowly forever. Now try and upload code from the IDE - it should report something about "Auto reset failed" and then sucessfuly upload code.

Posted 5 years ago #
DaemonMaker
Member

To answer your questions, yes it does run blinky. It also successfully runs the programs I upload with the IDE.

git tells me that I'm on the master branch for both code bases. Should I be using stable by chance?

1) This fixed it (Thanks!). The IDE shows 6 options under Tools -> Serial Port
/dev/tty.Bluetooth-Modem
/dev/cu.Bluetooth-Modem
/dev/tty.Bluetooth-PDA-Sync
/dev/cu.Bluetooth-PDA-Sync
/dev/tty.usbmodem411
/dev/cu.usbmodem411

I had it set to use /dev/tty.Bluetooh-Modem. When it's set to use /dev/tty.usbmodem411 it works just fine.

2) Yes, this works just as you describe.

Thanks again,
Dustin

Posted 5 years ago #
structuresound
Member

I recently uploaded the bootloader via serial to my R3 using the python loader from shell (OS X) i.e.

python stm32loader.py -p /dev/tty.usbserial-A8007ZPL -evw /maple_boot-rev3-9c5f8e.bin

the python script wrote, read, and verified, now when I reset the maple board I get stuck in "slow blinky" (or permanent bootloader) and the maple doesn't show up as a network or serial device. Any ideas?

I was messing around with JTAG stuff earlier so perhaps I've messed something else up!

Edit: I know this an old thread but it seemed a relevant to continue?

Posted 5 years ago #
poslathian
LeafLabs

When you reflash the bootloader, there is no code in RAM or Flash to jump to, so the device just idles in the "permanent bootloader mode" for a while. This is expected.

Now that youve got it in permanent bootloader mode, you shouldnt expect it to come up as a serial or network device. Its not! its a DFU device, patiently awaiting new code. The auto-reset from the IDE during programming will fail, thats OK - because its already reset and waiting for new code.

You should be able to upload code from the IDE in this state. You can verify that the device is coming up as expected by running

dfu-util -l

if you dont have dfu-util installed, you can get it from your maple install directory. On a mac, you can descend into the application folder, from there - dfu-util is located at:

hardware/tools/arm/bin

Posted 5 years ago #
structuresound
Member

worked like a charm, thanks so much. Glad this is here now for future readers too!

Posted 5 years ago #
samtal
Member

Worked for me too.
Thanks.
Strange, but I could not belive I can try to program the Maple if it was not recognized as a serial port (there was no port number to use for the IDE).
It works nice and clean, the port number showed up after program load (I used one of the example programs fore that).
samtal

Posted 4 years ago #
mbolivar
LeafLabs

samtal,

see here for why you don't need to select a serial port after the first time you upload a new bootloader:

http://forums.leaflabs.com/topic.php?id=891#post-5468

Posted 4 years ago #

RSS feed for this topic

Reply

You must log in to post.