Bootloader overwrites itself ...

[scotty264]

Hello:
Thank you for the effort to port OptiBoot to the Tiny85 ... in assembler, no less.

I am a little unclear as to the actual operation of the "virtual boot partition" and why is the WDT IRQ vector used to pass control to the application?

It looks as though OptiBoot85 remaps IRQ vectors on-the-fly when transferring blocks into RAM before executing the SPM command. Because of this, OptiBoot85 must be the only code written to FLASH and then should be the only application to load code into a Tiny85, yes?

I can deal with that but there seems to be no bounds checking on the uploaded code because the bootloader overwrites itself when loading application code that runs into its own code. Seems this coule be simple enough to do and just refuse to write the code while letting the AVR109 programmer think all went well.

I am using OptiBoot85 with AttoBASIC and thus able to extract routine entry points and make AttoBASIC aware of OptiBoot85. In the "appstart" routine, I have set YH:L to 0xAAAA and then allowed the IJMP to 0x0000. On a RESET or power-up, within a few instructions of the RESET, I check for YH:L = 0xAAAA. If not, I pass control to 0x1F00 (16-bit at 0x0F00). OptiBoot will time out and IJMP to the RESET vector with 0xAAAA held in YH:L and thus AttoBASIC continues its initialization.

I have yet to trouble-shoot the OptiBoot85 code for if I set BLINK=0 then the "flasher" code is disabled but OptiBoot85 does not operate correctly. Disabling the LED flasher code frees up about 32 bytes of code.

It would have been nice if ATMEL had provided a bootloader region on this part. 8KB of FLASH in an 8 pin device is handy. :)

Are there any plans for any future modifications on OptiBoot85?

Once again, thank you for your effort.

Peace and blessings,
Scott

[rufferson]

Hi Scott,
Thanks for your review of the code and the process. Honestly it's light version so certainly it doesn't have many features of the full-blown boot loader.
VBP is a name used in original optiboot code for hardware feature of the higher ATmels which is emulated in this optiboot by WDT vector and on-the-fly code patching as you correctly noted. WDT is used simply bcz it's easy to exit from loader code at any place on whenever WD fires.
If you deal with arduino (as I do) - it has built-in protection from overwrite so I didn't bother with that. But if you intend doing more complex stuff out of arduino app - memory wrap could really be an issue. I'll try to make another release (branch) with boundary checks instead of led flashing (to preserve code size). As for LED_START_FLASHES=0 - honestly I never tested this mode, will try it out on weekend.
Regards,
Ruslan
P.S. I'm afraid if atmel put a loader section to at85 - it wouldn't be so awesome anymore ;)

[scotty264]

Hi Rusian:
Thanks for the quick response.

Yes, I do work with ARDUINO platforms. The boundary checking would be great.

I found a bug when the LED_START_FLASHES=0 and the LED FLASH code is disabled.

In the conditional assembly statement block for "#if LED_START_FLASHES > 0", the WDT setup is contained within it. The code is:
ldi r24, 0x0F ;Set WD Params: Set WDE(WDEnab)
rcall watchdogConfig ; Call watchdogConfig

I see that the WDT is used to break out of the "GetChar" routine called from:
LoopMain:
rcall GetChar ; r24=GetChar() : Read Command Byte

However, once the LED_START_FLASHES code is disabled, the WDT is never init'd and thus "GetChar" waits forever to see the RX pin change state. The fix is to move the two lines for WDT setup outside the LED_START_FLASHES conditional. I moved it just under the "initVars:" label. Now the code works.

Also, at the beginning of the code, when the EXTRF bit in MCUSR is checked, the code being:
out MCUSR, r1 ;Reset Control Register to 0x0: R01 -> MCUCR
sbrs r24, 1 ;Check EXTRF bit of MCUSR was set
rcall appStart ; If ISC is off - we exit: appStart()

I think that the "rcall" to "appStart" should be an "rjmp". The stack pointer is left with the return address and "appStart" does an "ijmp" to the RESET vector at 0x0000 so the return address never gets removed from the stack. Is there a specific reason for using the "rcall" over the "rjmp"?

In my application, I am checking the EXTRF bit in MCUSR and passing control to OPTIBOOT85 if an external RST has occurred. OPTIBOOT85 clears the MCUSR before the WDT times out and passes control back to the RESET vector (my app) if no bootloader activity is detected.

I do not use GITHUB so I am not sure how to apply the patches to the current code and submit them.

Peace and blessings,
Scott

[rufferson]

Hi Scott,
Excellent findings, and certainly all make sense. Once you got required functionality you're losing focus on the stuff bcz it just works - so definitely I didn't make extensive tests once tiny started blinking and flashing :)
rcall - that was a mere oversight - desasm apparently translated C call to rcall and i just left it as it was.
WDT initialisation - that's a clear bug, after I've made blinks conditional.
As for EXTREF - let's try it this way (see last commit).
Regards,
Ruslan

[scotty264]

Hi Rusian:
Actually, I wasn't making the suggestion to leave the MCUSR alone for the application to see as I was using it to tell my app to pass control to OptiBoot85 based on EXTRF being set. This is because in my initial FLASHing, I am including OptiBoot85 with my HEX image, thus my app runs from the reset vector and passes control to OptiBoot85.

Now this brings up an interesting situation that I'll have to research because I have not yet tested for letting OptiBoot85 FLASH some code for me. I know the RESET vector is changed so I'll have to see what happens. Since the RESET pin is disabled during DEBUGWIRE and I cannot make the EXTRF bit "stick" during emulation, it poses some problems trying to properly debug on the tiny85.

I recall, clearing the MCUSR was a problem for me in the original OptiBoot V5.5 for ARDUINO. I was needing to see the MCUSR bits in my app once control was passed back to my app from an OptiBoot timeout. OptiBoot V5.5 cleared the MCUSR so I changed the code in OptiBoot so the MCUSR register was not cleared. The difference between OptiBoot and OptiBoot85 being, of course, is that there is a hardware BOOTRST vector on the ATmega parts and not on the ATtiny parts.

It is probably best not to clear the MCUSR bits in OptiBoot85, as you did.

I'll let you know what I find.

Peace and blessings,
Scott

[scotty264]

BTW: I see no credits for you in the code. I would like to give credit for your effort in my sign-on screen. What should I use?

Peace and blessings,
Scott

[rufferson]

Hm, yes, always forgetting copylefts - license and credits :)

[scotty264]

So you want no credit then? :)

[scotty264]

Hi Rusian:
Still working with OptiBoot85.

The problem with using the WDT vector to pass control to the application is when one is using the WDT IRQ. Since OptiBoot85 changes that vector "on-the-fly", when the WDT is triggered, it causes the application to restart, which is not the intent.

I get that this method of passing control is what microneucleous does but it does cause problems. One fix would be to use a different IRQ vector but the same issue arises if the application uses all of the IRQ vectors.

In my case, I can make my code aware of OptiBoot85 so that a EXTRF flag detection passes control to OptiBoot85. I can include OptiBoot85's code in with my HEX image as well and that will work just fine but I want to also insure that OptiBoot85 will still function with other apps, including mine, if it is reloaded through OptiBoot85. But then the WDT vector remap is still an issue for me.

A suggestion is to modify the RESET vector on-the-fly as usual but to store the app's RESET address in EEPROM then load it into Z pointer before the IJMP to the app. This means, of course, that the app would have to be aware that two bytes in EEPROM are reserved so it does not overwrite them, probably best to use the last two bytes.

Interested in feedback.

Peace and blessings,
Scott

[scotty264]

P.S. There is an optimized version of the AVR305 Soft-UART in "picoboot" that trims another 12 bytes off the existing OptiBoot85 Soft-UART code.

[rufferson]

Hi Scott,
This is limitation of the software emulation - one way or another - application must be bootloader-aware - either of IRQ or of EEPROM. You can generate several versions and use one which fits the purpose, but that's all.
I cannot imagine where those 12 bytes could be cut off, softuart implementation is already skinny enough, will check though, thx for the hint.