Frequent programming defects - bootloader problem?

Discuss general Uzebox topics here: features, wish list. nice to have, etc.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Frequent programming defects - bootloader problem?

Post by CunningFellow »

Check the CRC of the SD to confirm it read OK to RAM
Check the Flash Byte-by-Byte to the RAM to confirm it flashed OK.

No need to calculate the CRC on a flash sector. You have an exact copy in RAM to compare too.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Frequent programming defects - bootloader problem?

Post by Jubatian »

That can be done, too, but you didn't save a CRC calculation with that. You still need to calculate the CRC for the SD sector, I suggested to just calculate it on the ROM data after it was written, so it checks both the SD read and the programming steps. Of course from the point of ROM wear, checking the verity of the SD read is better, but I think it is rather the programming than the read which fails (The single case which I could clearly observe, a random zero byte, was lot more likely a programming error than an SD read error. Due to the sequential nature of SPI, I wouldn't expect the SD access to fail at all, or if it fails, it is a total failure as the running code desynchronizes from the SD card's internal state machine).
CunningFellow wrote: I've already done CRC on read in C for ArtcFox to check his hardware (viewtopic.php?f=3&t=2252&start=120#p16206).
This topic also suggests that it is the programming which tends to fail, not the SD access.

The best solution would probably be halving the clock (PLL configuration, I guess) for the programming (and turning off the display), not only to reduce the chance of errors, but also the wear on the ROM of the microcontroller (not because of the errors, but because of the repeated programmings to get a game correctly written).
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Frequent programming defects - bootloader problem?

Post by CunningFellow »

I'm looking at it from a code size efficiency point of view.

CRC on the SD card has to be done to check it reliably. A 2nd read can only tell you one of the two reads is wrong, not which one.

A byte by byte comparison between flash/RAM will be cheaper on code space as it can share most of the loop code and you don't have to make the CRC calculation stand alone.

I am looking at everything in the bootloader at the moment to see how much code space I can trim off everything.

I think I can trim enough to make the bootloader video mode a LOT prettier :)
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Frequent programming defects - bootloader problem?

Post by Jubatian »

Well, better be correct than pretty there! (That is I suggest rather try the reduced clock speed writing than trying to get a better looking bootloader screen: be easier on the ROM of the AVR!)
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Frequent programming defects - bootloader problem?

Post by D3thAdd3r »

Let us know how it goes Cunning, I appreciate both of you guy's expertise on all these wide variety of things.

I guess there is no way around it, anyone having issues with SD will probably have to get a cheap ISP or Arduino and use that as an ISP to put a new bootloader on it. I doubt there is any malformed .uze file that could be created to somehow stack/buffer overflow to a known state where the SD->flash could point at the bootloader. Probably other details about programming bootloader I don't even know about.

Definitely it would be a nice feature for this bootloader to be able to update itself off the SD card. Or even having the ability to upload an image over serial cable. As a community, if there are a few needing it, I am sure we could work something out for the price of a '644+shipping to get a new version bootloader in anyone's hands that needs it too without buying an ISP just for that.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Frequent programming defects - bootloader problem?

Post by D3thAdd3r »

I lost track of what '644 I got with standard kits, but last I checked this was working for me on my consoles. I am fairly confident this matches what all Uzebox kits come with.

BODLEVEL - Brown-out detection disabled; [bodlevel=111]
OCDEN - disabled
JTAGEN - disabled
SPIEN - enabled
WDTON - disabled
EESAVE - enabled
BOOTSZ - Boot Flash Size=2048 words Boot address=$7800
BOOTRST - enabled
CKDIV8 - disabled
CKOUT - disabled
SUT CKSEL - Full Swing Oscillator; Start-up time: 16K CK + 0ms;Crystal Osc.; BOD enabled

direct fuse values are:
EXTENDED - 0xFF
HIGH - 0xD2
LOW - 0xD7

If someone finds out these are not what is sent please update the wiki page here. I think fuse values where already somewhere on the wiki, but seems worthy for front page as confusion came up multiple times with people building homebrew Uzebox versions and not working right.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Frequent programming defects - bootloader problem?

Post by CunningFellow »

Jubatian wrote:Well, better be correct than pretty there! (That is I suggest rather try the reduced clock speed writing than trying to get a better looking bootloader screen: be easier on the ROM of the AVR!)
I will try be correct AND pretty :)

Your suggestion of slowing down the clock for programming is a good one. It will only take a few bytes of flash to do that though. So plenty of space for being pretty.
D3thAdd3r wrote:As a community, if there are a few needing it, I am sure we could work something out for the price of a '644+shipping to get a new version bootloader in anyone's hands that needs it too without buying an ISP just for that.
For $3.50 delivered from eBay/China each person can have an ISP programmer themselves. That would be cheaper than domestic shipping to get a someone else to program your uzebox.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Frequent programming defects - bootloader problem?

Post by CunningFellow »

D3thAdd3r wrote: I doubt there is any malformed .uze file that could be created to somehow stack/buffer overflow to a known state where the SD->flash could point at the bootloader.
If the boot lock mode bits are set to prevent flashing of the boot section an ISP cable is the only way.

If the bootloader is not locked, it is very easy to make a UZE file that can update the bootloader.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Frequent programming defects - bootloader problem?

Post by Jubatian »

Maybe looking at BitBox's solution for the reprogrammable bootloader problem could be useful (it is here). The first stage for Uzebox would have the necessities for proper SD access and programming (providing those as interfaces as well), by itself capable only to silently load a second stage off of the SD card if present and different than what's already in. The second stage would contain the game selector UI, possibly including interfaces for reading the SNES controllers.

An interesting capability of this bootloader architecture would be that it would be also possible to design dedicated SD cards with it (that is a card having only a single game or a specific package of games) which would "autostart" if the Uzebox was powered up with that plugged in (simply the game or game pack would have to provide its own bootloader UI). This may also be nice for demos, which this way could work without any controller.
xiaolong
Posts: 12
Joined: Thu Nov 19, 2015 7:40 am

Re: Frequent programming defects - bootloader problem?

Post by xiaolong »

Just something to try if you have programmer. Posted this last year in "Evolution of the SD card API thread" but I guess it went unnoticed: "Noticed that Artcfox had had a problem that games would not start always. There was a similar behaviour on my Euzebox after compiling bootloader from source. After disabling interrupts in flashgame() by removing all sei() statements that problem was fixed. Side effect was that progress bar would not display anymore but that doesn't matter so much as games load so fast anyways :) "
Post Reply