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 »

I have never played it and all I know about Zelda is that he is a guy wearing a green hat. However I can see how an API in the boot loader that allowed you to say

"Burn these 512 byte sectors into this page of flash"

could be useful.

Whats a full feature list you would like? What checks and measures do you think needs to be in place? (corruption prevention, flash wear prevention, etc)
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 »

Flash Count: Any byte goes bad and the '644 is basically unreliable for code so partial or full flash counts the same really. Perhaps store it the kernel's eeprom somewhere. That being said, I don't think this is necessary assuming responsible programmers who use it in places with forced delays. If you use it to change dungeon tiles as in zelda example, it is say 5 seconds total transition time(in dungeon entrance, screen fade out/in, show dungeon, go out, screen fade out,in, show overworld, etc.) for fastest possible back to back tile set changes. You would have to do that non-stop for nearly 6 days(138 hours) to hit 100,000. I honestly doubt any Uzebox will get 138 hours of play time total, let alone that entire time spent trying to destroy the 644.

Corruption Prevention: I think this is quite important for gameplay experience/integrity. I have not experienced this issue myself, but it would be really frustrating and hinder enjoyment of the hobby. I am staying out of this one because I don't know much about it. If the SD CRC is good enough then it seems useful, since you have to spend the time to SPI out those bytes anyway.

Speed Control: maybe software can use a slower speed in cases where it doesn't need to be too fast(really should not be using this feature where it has to be fast) to increase reliability?

Past that I can't come up with anything besides the obvious.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Frequent programming defects - bootloader problem?

Post by CunningFellow »

flash endurance is only 10K cycles
EEPROM is 100K cycles

If Zelda really needs to change tilesets every 5 seconds - then that is only 14 hours of play time before the AVR is toast.
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 »

Ha I was off by some orders and maybe a magnitude or so. Still as merely reductio ad absurdum, even 10k is a big number if we then look at realistic usage instead of intentional breakage.

I would guess a mega play session of several hours on a Zelda 1 like would result in 30 flashes max.
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 »

Just dropping a note here for now.

The programmer arrived (since a while, I admit), and I will look into the bootloader posted by Xiaolong whether it does anything good to the flashing issues I experience. I am just not confident enough that I won't brick the Uzebox somehow in the process that I would be left without real hardware to use as there is noone here to help me in any manner if I do. But this problem seemingly became quite urgent to solve.

By the way, where is some documentation if there is anything on how to do the programming? I mean in particular with the power supply, if I plug in the programmer, how I should except it to work, what I need to be cautious about? (In particular I am worried about whether the programmer might try to power an already powered Uzebox which could spell a smoky disaster).

Xiaolong: did you attemt to add any kind of verifications whether a write succeeded?

Theory: If the bootloader doesn't span the entire boot section (where issuing an SPM is allowed), would it be possible to come up with a method to reflash the bootloader itself? (I could imagine if it allowed to write into that zone, that could be used to upload a flash writer as a part of a larger program which could replace the bootloader, that is, it would be possible to upgrade it)
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Frequent programming defects - bootloader problem?

Post by Artcfox »

Jubatian, which programmer did you get?

Edit: Nevermind, I read a few posts back. That one looks like it can power the board, or not power the board with a switch. It also looks like it has a 10-pin cable, which you'll likely have to make an adapter for so you can use it with the 6-pin ICSP connection the Uzebox expects. That's not that difficult of a job, just look at the pinouts, and triple check that you wired the adapter correctly.
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 »

I have exactly this Pocket AVR Programmer (was about the only thing which would ship to Hungary at all :P ) It has the 6 pin cable included with it.

Oh, damn, now I see that tiny switch. Well, I am an embedded developer by profession, but only a software engineer, having no skills in electronic at all. Usually the programmers I came across had settings to switch power within whatever IDE they had, on Windows. Now only having Linux and command line stuff not necessarily developed by the original manifacturer, I was really worried that one way or another I would misconfigure it, and there is no second life to try it again here. I will be glad if I will see that switch on the real thing (at home), and I can flip it off for sure.
Last edited by Jubatian on Wed Sep 21, 2016 6:23 am, edited 1 time in total.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Frequent programming defects - bootloader problem?

Post by Artcfox »

Jubatian wrote:I have exactly this Pocket AVR Programmer (was about the only thing which would ship to Hungary at all :P ) It has the 6 pin cable included with it.
That's awesome that it includes the 6-pin cable with it! The biggest gotcha I think you'll need to remember is to remove the SD card while you're using the ICSP.
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 »

Artcfox wrote:The biggest gotcha I think you'll need to remember is to remove the SD card while you're using the ICSP.
That I suspected from the pinout! :) The power worried me the most, see above (edited), but of course anything else which could turn the thing into dust and smoke by a single push of a button (or plug or a tap on Enter in Bash).
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Frequent programming defects - bootloader problem?

Post by Artcfox »

Jubatian wrote:
Artcfox wrote:The biggest gotcha I think you'll need to remember is to remove the SD card while you're using the ICSP.
That I suspected from the pinout! :) The power worried me the most, see above (edited), but of course anything else which could turn the thing into dust and smoke by a single push of a button (or plug or a tap on Enter in Bash).
FWIW, I never really use bootloaders in any of my personal projects, I much prefer just using the ICSP to program chips. Once you do it a few times, it shouldn't be scary. Do you have any other AVR chips that you can play around with first, like an ATmega328, or an ATtiny85. Even an Arduino board can be used with the ICSP.
Post Reply