Alternative experimental bootloader by Jonnection, version 2

Libraries, utilities, bootloaders...

Re: Alternative experimental bootloader by Jonnection, versi

Postby rodot » Wed Aug 06, 2014 8:35 pm

Hey there, I tried your bootloader on an SD card which was acting erratically... now it works fine, that's really promising. Thanks for you work :)
I noticed that the power light and back-light flicker during flashing, anybody else has this issue?
User avatar
rodot
Site Admin
 
Posts: 1290
Joined: Mon Nov 19, 2012 11:54 pm
Location: France

Re: Alternative experimental bootloader by Jonnection, versi

Postby rodot » Wed Aug 06, 2014 8:43 pm

Hey there, I tried your bootloader on an SD card which was acting erratically... now it works fine, that's really promising. Thanks for you work :)
I noticed that the power light and back-light flicker during flashing, anybody else has this issue?
User avatar
rodot
Site Admin
 
Posts: 1290
Joined: Mon Nov 19, 2012 11:54 pm
Location: France

Re: Alternative experimental bootloader by Jonnection, versi

Postby jonnection » Wed Aug 06, 2014 8:59 pm

hey Rodot

Thanks for the feedback, I was really waiting for you to comment.

About power led / backlight flashing. Nothing that I have done in the code by itself can cause these errors.

BUT it is a very interesting observation, because:

I have been scratching my head about what on earth is causing these problems with SD cards. It does not make sense why some cards work and others do not. I am interested in finding the root cause for these problems. The SD card is the best feature of the Gamebuino, and we must try to make it work 100% reliably.

Flashing power led / screen flicker may be an indication that voltages are not holding still. Something is drawing more power than can be supplied.

I have a theory, but it is only a theory. You see, I read somewhere (AVR datasheet or something) that flashing the memory requires quite a bit of current. In the old days, flashing also required much higher voltages.

Here's an old posting about it

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=14292

Now, since the Gamebuino is only operating at 3.3 V, is already overclocked, is trying to access SD card and flash the program memory, sometimes only supplied by battery voltage ...

... is it possible that the Gamebuino simply runs out of "juice", voltage drops below critical level, and the BOD (brown-out detection) of the AtMega kicks in ? The display will still hold the picture, because it has its own controller chip. Perhaps also some SD cards "draw" more current during reading than others, and that makes them unreliable ?

Also, others claim to have seen bootloaders get corrupted in too-low-voltage flash_writes.
Last edited by jonnection on Wed Aug 06, 2014 9:12 pm, edited 1 time in total.
User avatar
jonnection
 
Posts: 317
Joined: Sun May 04, 2014 8:21 pm

Re: Alternative experimental bootloader by Jonnection, versi

Postby rodot » Wed Aug 06, 2014 9:08 pm

I agree with you, that's exactly what I thought. A sudden high current draw can create a voltage drop. Anybody has an oscilloscope and a current probe to check that?

I used the following fuses for all the Gamebuino, so brown-out detection should be disabled according to fusecalc. Edit: the brown out detection is already at 2.7V
gamebuino.bootloader.low_fuses=0xff
gamebuino.bootloader.high_fuses=0xda
gamebuino.bootloader.extended_fuses=0x05

But as your told, it's already over-clocked so a voltage drop could make the atmega unstable.

But then I wonder... if voltage drop was the problem, why does your bootloader work better than the official one?
User avatar
rodot
Site Admin
 
Posts: 1290
Joined: Mon Nov 19, 2012 11:54 pm
Location: France

Re: Alternative experimental bootloader by Jonnection, versi

Postby jonnection » Wed Aug 06, 2014 9:35 pm

rodot wrote:But then I wonder... if voltage drop was the problem, why does your bootloader work better than the official one?


Because I disabled double speed reading from the mmc_fat.c read_first_sector (or something like that) function that is actually used in all the SD read operations done by the bootloader.

Double speed reading probably requires more current than single speed reading.

If you read that AVR Freaks forum posting that I linked, they say that you MUST use BOD function to prevent the MCU doing all sorts of funny stuff (even corrupting the bootloader) in undervoltage situation when using SPM (program memory flashing) commands.

There are improvements we could try to the bootloader to make it even more reliable. The TinyFAT library uses CRC checking to ensure the sector has been read correctly. The mmc_fat.c that is a part of the bootloader does not. We could implement CRC check on the SD sector read to ensure that no rubbish is written into the progmem.

Another thing we could try is to have a small pause between sector read from card and page write to flash. This will possibly allow the voltage to stabilize before we start writing the flash. Because Gamebuino games are so small, the user probably would not even notice that the process is slightly slower.
User avatar
jonnection
 
Posts: 317
Joined: Sun May 04, 2014 8:21 pm

Re: Alternative experimental bootloader by Jonnection, versi

Postby rodot » Wed Aug 06, 2014 9:48 pm

jonnection wrote:Because I disabled double speed reading from the mmc_fat.c read_first_sector (or something like that) function that is actually used in all the SD read operations done by the bootloader.

Oh, i thought I already disabled the SPI double speed, because I noticed that some micro SD card couldn't work at high speed. I actually noticed that loading was longer with your loader. I'm almost certain that it's what solved the problem.
The read/write speed of a micro SD card is not the same when you are on a computer because it communicates in parallel on all pins. The SPI speed of the micro SD card is never given by the manufacturer and is pretty low (and random from on card to the other).

jonnection wrote:If you read that AVR Freaks forum posting that I linked, they say that you MUST use BOD function to prevent the MCU doing all sorts of funny stuff (even corrupting the bootloader) in undervoltage situation when using SPM (program memory flashing) commands.

I'll set the brown out detection at 2.7V then.
Edit: the brown out detection was already at 2.7V, my bad.

jonnection wrote:We could implement CRC check on the SD sector read to ensure that no rubbish is written into the progmem.

I thought it was already difficult to fit the bootloader in 2KB, is there enough free space to add CRC check?
User avatar
rodot
Site Admin
 
Posts: 1290
Joined: Mon Nov 19, 2012 11:54 pm
Location: France

Re: Alternative experimental bootloader by Jonnection, versi

Postby rodot » Thu Aug 14, 2014 10:41 am

Hey there,
I'm going to update the official bootloader (on the beta branch for now) with your version, are your hex file on drive and the sources you provide up to date? Thanks a lot for the great work :)
User avatar
rodot
Site Admin
 
Posts: 1290
Joined: Mon Nov 19, 2012 11:54 pm
Location: France

Re: Alternative experimental bootloader by Jonnection, versi

Postby jonnection » Thu Aug 14, 2014 11:44 am

Hi Rodot

Thats great. The latest versions are in the links I have give, but I advice looking through the code just in case. I have commented the things I have changed.

The delay for the C button debounce is a bit long, you could reduce that or leave it out. I put in a mydelay() function, it was a quick and dirty fix.

I can test the beta branch once you're ready.

By the way, I also came up with an idea how to make a sorting loader.hex. It really works, but I need to clean it up and test it thoroughly first.
User avatar
jonnection
 
Posts: 317
Joined: Sun May 04, 2014 8:21 pm

Re: Alternative experimental bootloader by Jonnection, versi

Postby rodot » Thu Aug 14, 2014 11:52 am

Okay then could you removed the C button delay and update the source and .HEX please? I don't have the tools to compile it and I don't want to mess everything up in the bootloader :P
Nice for the .hex sorting, I look forward trying it :)

Edit: I just tested the .HEX file you provide, I don't have to hold down C for 3 seconds for the loader to trigger when I restart my Gamebuino
User avatar
rodot
Site Admin
 
Posts: 1290
Joined: Mon Nov 19, 2012 11:54 pm
Location: France

Re: Alternative experimental bootloader by Jonnection, versi

Postby jonnection » Thu Aug 14, 2014 12:11 pm

Hey Rodot

OK, lets do so. I'll look at the code and clean it up. If you want, I can commit to the Beta branch directly, I use git daily.

Rodot, please select the changes you wish me to make

a) disable double speed in to improve sd read stability (Y/N)
b) use Adaboot MCUSR trick to detect between hard/soft boot (Y/N)
(official bootloader jumps over this. Prevents endless flashing.)
c) debounce C button at start (Y/N)
(This feature improves C button detection on Fakebuinos and breadboarded Gamebuinos with higher capacitance. Official gamebuinos do not seem to have problems with this. )
d) use _normal flash routines instead of _small (Y/N)
The difference is that _normal versions require a few more bytes, but are according to ATMEL application examples. _Small versions were developed by Optiboot authors, and use some register tricks to reduce bootloader size. I do not know if they really make any difference in reliability. At the moment, the official bootloader uses _small versions.

There is still around 100 bytes left of space, so it is not a matter of whether the bootloader will fit or not. As you know, the fusebytes dictate that the bootloader is 2k in size, and if the bootloader is 1.7kB or 1.9kB does not make any difference for Gamebuino users.
User avatar
jonnection
 
Posts: 317
Joined: Sun May 04, 2014 8:21 pm

PreviousNext

Return to Software Development

Who is online

Users browsing this forum: No registered users and 18 guests

cron