Please help me - I ruined my bootloader!

[mario1089]

Damn, I unintendently pressed a wrong key and started uploading a firmware that was some bytes too big. Since that I can not upload anything anymore ("Could not get IDstring"). Can anyone help me out?

[antto]

with c0nb0x?!
i don't remember exactly (wrote it a bunch of months ago) but it shouldn't let you upload it, or at least warn you that the hex is too big
what happened exactly?

the silly thing is, the bootloader is NOT protected, at least on my x0x it isn't
and since it sits on the last 512 bytes of the flash - it is easy to overwrite it if you have big enough hex, but still, c0nb0x should have prevented that

[mario1089]

Yeah, conbox told me its too large -- some silly number at "remaining" ( guess a negativ value on a uint ) and I saw it and wanted to not upload it and do some more size optimizations and, well, it was late in the evening, and I somehow did not press escape but some other key. There it went overwriting the bootloader.. I guess it would be very reasonable to make that impossible to happen (maybe the code is there already, but is just confused by the uint, that does not go negativ).

[antto]

it's a bug

Code: Select all

                            uint32_t flashsize = flash_total - bl_size; // bl_size is the size of bootloader
                            ...
                            echo << "\nHEX file loaded.";
                            echo << "\nStart    = " << hex.get_start();
                            echo << "\nEnd      = " << hex.get_end();
                            if ((flashsize - hex.get_end()) < 0)
                            {
                                echo << "\nError: potential collision with bootloader.";
                                echo << "\n           " << (hex.get_end() - flashsize) << " bytes over the limit. Aborting.\n";

                            }
                            ...


the if statement, the calculation is unsigned and thus the comparison is always false, it was supposed to always abort
i didn't test it since i don't have a large .hex myself

[antto]

i can recompile the win32 version right away, but for the mac osx version i rely on someone else

[mario1089]

See, just what I said:)

Unfort. I`m one of that PC-only-and-this-will-never-change-developers:) Who compiled it last time?
(I got some friends around, who would propably do us that favour..)

[antto]

darffader compiled the mac osx version, he is at the irc channel regularly, so he is aware of this
i already fixed the bug, haven't tested it, i need a big .hex for that
if you haven't erased the problematic .hex - it'd be good if you can upload it so i can use it to test this

i feel terrible, the compiler didn't give warning about that, i just checked, my compile flags have been -Wall
it only warns about this ((unsigned int) < 0) comparison with -pedantic or -Wtype-limits (gcc)

[mario1089]

I`ll send you a bigger-than-allowed-hex in an hour or so.
yes, I also would have expected the compiler to throw a message about that. I mean, they normally do..

[mario1089]

Attached: Bigger than allowed hex file.

DONT USE IT EXCEPT IF YOU`RE ANNTO AND WANNA TEST C0NB0X!!

[antto]

interesting, i can't even attempt to upload this because my hex-parser already aborts this
the total flash size (16kB, not taking into account the bootloader) is used for the hex-parser
it has it's own protection to reject loading the data if it's above 16kB in this case
thus even with the bug in v0.99 - this hex you attached should immediately spit you in the main menu without even printing an error
for the bug to work, the hex must be longer than the (flashsize-bl_size) but yet shorter than (flashsize)

i'll put even more error messages in these situations to make it clear when something goes wrong - what exactly is wrong

[mario1089]

Yep, when I scrambled my xox, it was all like 20 bytes too much, find something to optimize, and so on, so always just on the edge. this one I made really big just by adding some stupid table. I can give you one, thats more at the edge, later..

[antto]

fixed the bug and tested it
it catches both if the hex is bigger than the whole flash size, as well as if it's colliding with the bootloader

i didn't expect to have to release v1.00 so soon (i expected to get some feedback like ideas for features or changes..)
..so i have to document some of the changes and new things that i already had, and will release it these days..

[antto]

now, i guess you have tryied to connect with the bootloader again and upload a normal firmware
and if you are fully sure the bootloader is dead (not-working) this app won't help

to restore the bootloader - a special programmer tool is needed (which i don't have)

you can send the chip (the atmega162) to someone who can program it
or buy a pre-programmed atmega162 (with bootloader)

you might be able to find some friend electronics geek who has such a programmer to do you a favour..
x0xsh0p.de and willzyx *might* be able to re-program the bootloader on your chip, but then you'd have to ship it, so it might be cheaper to just buy a new chip with pre-programmed bootloader and OS

the bootloader is available at the x0xb0x sourceforge.net page

i still don't understand why the fusebits are not set to protect the bootloader from writing

[mario1089]

Looks like I can borrow a CPU for some days until I get a new one sent, but as you`ll understand I wanna be on the safe side with that disaster not happening again.. so, antto, can you release a conbox with only that fix in today or tomorrow?

[antto]

https://www.box.com/s/idqqsabsif2035gy0uyj
note: this is not v1.00 officially