SerialUSB behaving differently when uploaded to FLASH.

LeafLabs Garden » Support » Maple Hardware Support

SerialUSB behaving differently when uploaded to FLASH.

(26 posts) (7 voices)

Started 5 years ago by Amir Hadzic
Latest reply from Amir Hadzic

12 Next »

Amir Hadzic
Member

Hi!

I'v received my Maple just a few days ago and started playing with it. At first I used the IDE but I needed micros() so I cloned the git repository and started using the unix-toolchain (maybe I could have just used the new libmaple with the IDE, but meh, I like the terminal more). I have noticed some "strange" behavior. I tried to print out some debugging information over USB, but it didn't work.

I opened the ASCII table example and uploaded it to RAM. Tested it out and it worked. Then I uploaded that same sketch without any modifications to FLASH and it didn't work. Any pointers?

Let me know if you need any additional info. Thank you!

Edit: I have unplugged and plugged back in the usb cable. Then I uploaded the sketch to FLASH again. And now it works...

Posted 5 years ago #
Amir Hadzic
Member

It's happening again. I will be more specific this time. I have used this code to receive some signals from an IR module. Basically I'm debugging it right now, trying to find the right pulse timings. Every time I call SerialUSB.println() execution of the whole program just stops. If you look at the code, you will see that there's only one call to SerialUSB.println and if I remove that line the LED blinks for one second every time it receives any kind of pulse on the IR module. If I leave the SerialUSB.println("Blink!") line then I get "Blink!" on the serial monitor but the LED doesn't blink and also, any subsequent pulses are not detected -- the execution just stops at SerialUSB.println("Blink!")

Posted 5 years ago #
bnewbold
Ex-Leaflabs

This is definitely unexpected behavior. Memory access times for code stored in Flash are a little longer than for RAM, and USB timing is quite picky, so that might have something to do with it. There may also have been a problem with linking.

We might not have a chance to get back to you with a better answer in the next day or two, but we'll take a look and try compiling your code as soon as we get a minute.

Posted 5 years ago #
Amir Hadzic
Member

Ok'e and please notice that this is happening also when uploaded to RAM. Also, this is happening only when using the unix-toolchain with the latest libmaple (from the git repo). I can't compile this code with the IDE and the libmaple that comes with it (micros() is not implemented in it) but the ASCII Table example works if uploaded from the IDE.

Posted 5 years ago #
Amir Hadzic
Member
I have also tried using the latest IDE. Same results. It hangs at SerialUSB.println("Blink");.

Steps to reproduce:
1. clone the maple-ide
2. compile and run it
3. load this code
4. upload to the maple board (FLASH or RAM, it doesn't matter)
You will notice that it sends "Blink!" over the usb once and then nothing happens. Also, you will need to restart the board in order to upload again.
Posted 5 years ago #
poslathian
LeafLabs

I will have to take a closer at reproducing the error you described in the last post ("blink"). However, the first problem you were having sounds like RAM/Flash contention.

Upon Bootup, maple first checks whether there is code in RAM, if so, then it jumps, otherwise it checks for code in flash and if so then jumps. Otherwise it idles in the bootloader.

This means if you upload code to ram, and then upload code to flash Maple will run the RAM code (not the new code!) until you unplug and replug to clear the RAM. This bug has been fixed in the new rev of the bootloader, but it exists in the boards currently in the field.

Posted 5 years ago #
poslathian
LeafLabs

Also, halting on USB r/w is a bug back from the dead! We were having this problem a few months ago, and "fixed" it via tweaking how the serialusb stack responds to DTR/RTS signals from the host. However, since every OS/serial terminal behaves slightly differently in its use of DTR/RTS, this was a notoriously difficult problem to fix. It sounds like it has not been fixed after all! Can you please dump your system info (OS, serial program youre using, etc).

Posted 5 years ago #
leaflabsandy
Member

Quote: "This bug has been fixed in the new rev of the bootloader, but it exists in the boards currently in the field."

Reply: Where can this new and improved bootloader be found at?
I have a June/2010 bootloader. Is there newer one created after the June/2010
for the Maple rev. 3 (red)?

Note: Using the Modern Device's USB/3.3 TTL BUB converter $14 USD and STM's free
flash loader, a person "in the field" could reflash his/her bootloader on Comm #1
if they are careful? <------

Posted 5 years ago #
Amir Hadzic
Member
I have just tried running the example I posted above and it kinda worked. If I'm not using the serial monitor the LED blinks. If I use the serial monitor, I receive data (continous "Blink!" lines) but the LED doesn't blink. This is really weird, and hard to explain as the bug "symptoms" change from time to time :\ Also, when I close the serial monitor, the LED starts blinking again.

Serial communication (same symptoms on all):
- maple-ide serial monitor
- screen
- putty
OS Info:
- Archlinux
- Kernel: 2.6.35-ARCH
- 64 bit
- Any other info required?
And thank you for the information about uploading to RAM/FLASH - that explained a lot of things :-)

Edit: Tested on Debian 5.0 (2.6.26-2, 32bit) -- same results.
Posted 5 years ago #
bnewbold
Ex-Leaflabs

Hi amir,

In the code you posted above, the LED should not blink unless the SerialUSB is timing out. When you are connected, the LED will only be off for the amount of time that it takes to send data and then will turn back off again (and will look like it never blinked). I've run in to this situation a number of times myself and it's why the example code always has that toggle variable; I usually just put a 500ms delay after both the HIGH and LOW writes.

Posted 5 years ago #
Amir Hadzic
Member

Well, this is embarrassing :P *crawls back under a big rock*

Posted 5 years ago #
bnewbold
Ex-Leaflabs

I think your above problems may be due to a recently discovered bug where micros() kills USB... I think this is due to the new micros() toggling the global interrupt flag (which we haven't tested much yet), but we'll have to have perry look at it.

Posted 5 years ago #
Amir Hadzic
Member

Yup, after testing the first example I posted here (the one that uses micros()) the USB stopped working again. I thought that it's my fault (again) so I didn't want to post here :-)

Let me know if there is a workaround. Thank you!

Posted 5 years ago #
snigelen
Member

A workaround is to use one of the hardware USARTS for communication (but then we don't get important bug reports like this). I find it very handy to use a FTDI module or a FTDI-cable. Note that thay come in both 3.3V and 5V versions, so be careful with the 5V variant with USART2 which isn't on 5V tolerant pins.

Posted 5 years ago #
Amir Hadzic
Member

That's quite an expensive workaround. You can almost buy an maple board for that cable + module.

Posted 5 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.