LeafLabs Garden

A place to share, learn, and grow...

1. 

   starbug
   Member

   Received my Maple board today and started installing the software. Everything was fine. DFU ok, Serial ok. Serial Port was COM8. Compiled Blink. Uploaded to board, worked perfect. Changed delay times uploaded and had the first error that dfu-util did not find Maple after reset. Ok. Reinstalled serial port software. Worked again, altough i had to try upload several times until the proggy was loaded and the prog was working. Tried a new sketch "ASCII Table" to test the serial port. During the upload the programm blocked and refused to work. Since that time, after Reseting the board, the led starts to blink fast and after ten slow blinks the led stays dark. The serial Port COM8 is not available any more and Windows XP does not recognise the board anymore. What have i done wrong. To be honest, not a very exciting first contact with Maple. But any help is welcome.

   Posted 5 years ago #
2. 

   perry
   Administrator

   Hi starbug,

   Haven't seen that before, but we'll look into it.

   Which operating system are you using? 32-bit or 64-bit?

   Also please try hitting reset on the board, and while the bootloader blinks are happening, hit upload, and let me know if the upload was successful.

   Getting the serial port to work across all of the various flavors of windows, mac, and linux have been and continue to be a difficult problem. We're working on ironing out the kinks, sorry for the trouble!

   Posted 5 years ago #
3. 

   starbug
   Member

   I am using Win XP 32.
   Hitting reset on the board while bootloader blinks does not lead to a success as there is no DFU device. Windows message: USB DEVICE not recognised.
   Malfunction of board or what? Will i have to flash a new Bootloader? Its not that easy for me to get some other support as i am located in europe.

   Posted 5 years ago #
4. 

   stars
   Member

   Hey Starbug!

   I ran into a possibly-related issue to yours -- except, I was intentionally ripping the USB cable out of the maple while it was programming (I know this is a terrible idea, but it worked for what I was trying to do at the time), and ended up bricking the maple (rather than the program blocking -- and no big surprise.)

   I re-flashed the bootloader (which was incredibly easy to do) and the maple returned to working again. Just follow the directions at: http://forums.leaflabs.com/topic.php?id=32#post-126. I expect it would take maybe 2 hours if you have to make the cable etc. to connect through the FTDI cable.

   Posted 5 years ago #
5. 

   starbug
   Member

   Hi stars,
   thanks for your idea. I have already built a Flasher hardware with a basic breakout board for the FTDI on a Arduino proto shield. Started the Flash Loader Demonstrator from STMicroelectronics, set the parameter for the serial port, it took me some time to get the Maple into serial bootloader mode but it worked and the FLD answered with
   "Target is readable. Please click next to proceed." I proceeded up to "Download to Device" with the File "maple_boot-rev3-8b4cea-rev1-mods.bin". This is the only BL bin File i could find. Checked the box at "Erase necessary Pages". Next the pulldown is set to @ (h) 8000000. After pressing Next the download started and the result was "Download operation finished successfully".
   After removing all the FLD Hardware i restarted the Maple. The result was zero. Same behavior as before. Windows still does not recognise the Maple as a USB Device.
   So what do now? Am i using a wrong bin file? Could you supply me with your bin file for a test? Or where can i get a Bootloader bin file for testing?

   Posted 5 years ago #
6. 

   bnewbold
   Ex-Leaflabs

   Hey starbug, we're still discussing on our end what might be giving you trouble, but in the meanwhile you can find the "regular" rev3 bootloader as a .bin file in this folder:

   http://static.leaflabs.com/pub/leaflabs/maple-bootloader/

   or the direct link is:

   http://static.leaflabs.com/pub/leaflabs/maple-bootloader/maple_boot-rev3-8b4cea.bin

   We usually use the stm32loader.py script instead of the STM Flash Loader program, but that should work as well.

   I'm guessing that the issue you're seeing is due to driver issues; either unsigned/unvalidated for your platform or a 32bit/64bit goof-up. We're going to set up an XP 64bit machine to check that exact configuration with our most recent release and will keep you updated!

   Posted 5 years ago #
7. 

   starbug
   Member

   bnewbold,
   thanks to your help MAPLE is alive again. It worked very well with the STM Flash Loader. But still i have severe problems with uploading from IDE. Sometimes it works and most of the times i have to press Reset and wait for a chance that Windows XP Home detects the Maple and uploading starts. I also think that this is due to the drivers and maybe the Dfu driver is causing the problems.
   These are the messages which occur mostly:

   Binary sketch size is reported above. Check it against a 100000 byte maximum.
   Loading via dfu-util
   Resetting to bootloader via DTR pulse

   Opening USB Device 0x1eaf:0x0003...
   Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="DFU Program FLASH 0x08005000"
   Setting Configuration 1...
   Claiming USB DFU Interface...
   Setting Alternate Setting ...
   Determining device status: state = dfuIDLE, status = 0
   dfuIDLE, continuing
   Transfer Size = 0x0400
   bytes_per_hash=221
   Error during download get_status
   Starting download: [

   And the the system stops and i have to press Reset and try again.

   Posted 5 years ago #
8. 

   poslathian
   LeafLabs

   This is, unfortunately, an incarnation of the "dfu timing bug." It first appeared in the wild here:
   http://forums.leaflabs.com/topic.php?id=37

   There is good news and bad. The good is that you shouldnt have to continually hit reset or hit reset then program, or some combination of thing. You *should* also be able to get a higher success rate by tweaking your "programDelay" field in your preferences (file->preferences). I recommend about 1200 if youre having trouble, 600 seems to work on quick systems.

   Perhaps also, and this is rare, the download operation dumped corrupt code. I've seen this happen, and its probably related to a misconfiguration of the CRC checksums on the USB hardware. When this happens, Maple jumps out of the bootloader to bad code, which prevents it from getting back to the bootloader via a serial reset. Here are some notes on this:

   1) upload new code (if you have space) to RAM first. So if its botched or broken, you can delete it my unplug/replug. Power cycling kills code in RAM
   2) If you do have some botched code in FLASH that seems to break everything (board doesnt reset on upload or usb interrupts are getting missed...or anything), then use perpetual bootloader mode to recover your board.

   If youre interested in the technical details of the problem (what is programDelay, perpetual bootloader mode etc), its poorly explained here:
   http://leaflabs.com/docs/maple-bootloader/

   To verify that the board is at least working, and that this is a timing bug (not something nastier), do the following:

   1) reset the board
   2) immediately after (during the fast blinks), press and hold the "BUT" button, through to the slow blinks. The board should now stay in bootloader mode forever.
   3) Windows should enumerate Maple as a DFU device, not as a serial device, and you should be able to upload code to RAM or flash.

   This method should always work, unless theres some really insidious problem. Beyond that, its a matter of tweaking the programDelay, which is an admittedly annoying and grungy solution. We're working on improving the whole dfu/serial/bootloader/reset assembly, when it comes right down to it, we might end up releasing OS specific bootloaders or something (ugh). Well keep you posted! Sorry for the hassle. This has been our #1 bug.

   Posted 5 years ago #

RSS feed for this topic

Reply

You must log in to post.