Page 1 of 1
possible to jump between bootloader and the main program?
Posted: Tue Jun 08, 2010 1:51 pm
by alex
Hello guys
nice forum, with a lot of problems...
thanks in advance for reading this topic
I run bootloadHID and I love it. In the main program i have the same code and
I want to switch between the main programm and the bootloader without reenumeration...
disconnect > reconnect... and so on.
Is this intention possible? Or do I break a lot of usb-rules by jumping out to the main program...
I tried to modify initForUsbConnectivity in main.c... but without a positive response
Re: possible to jump between bootloader and the main program?
Posted: Wed Jun 09, 2010 11:44 pm
by frank26080115
Code: Select all
typedef void (*AppPtr_t)(void) __attribute__ ((noreturn));
AppPtr_t AppStartPtr = (AppPtr_t)0x0000;
AppStartPtr();
That's code I found here
http://www.avrfreaks.net/index.php?name ... c&p=493336So modify it with the bootloader address instead.
Code: Select all
typedef void (*AppPtr_t)(void) __attribute__ ((noreturn));
AppPtr_t BootloaderPtr = (AppPtr_t)0xAddressGoesHere;
BootloaderPtr();
Re: possible to jump between bootloader and the main program?
Posted: Thu Jun 10, 2010 12:58 pm
by alex
thank you frank,
but this is not the main problem, the main problem is
that after entering the mainprogram the device does not recognize.
if bootloadercondition is not valid, my atmega168 enters the mainprogramm,
goes throw the initForUsbConnectivity(void) ---> disconnect -> reconnect
and it works...
I tried to modify initForUsbConnectivity(void) ... to take disconnect away, so
that the pc-side don't realize any changes... the result is, that something goes
wrong. I still see the device in windows, but my application can't get it...
I have to remove/modify something in my usbinit function... but I don't know where the problem could be.
Re: possible to jump between bootloader and the main program?
Posted: Thu Jun 10, 2010 6:48 pm
by frank26080115
Hmm... I don't think this is practical. The problem is probably due to memory (what variables is saved where).
If the generated HEX file is identical for both the application code and bootloader code (obviously with a offset in the flash address), then your bootloader can probably just skip usbInit and it "should" work. But this is not the case, it's just not possible with the circumstances you described.
The only way you can do this is to either make sure the variable somehow stay in the same place or a known location (a dedicated chunk in the stack maybe?) and have the bootloader read that location when it detects a jump.
If you were to just push and pop the V-USB variables into/from the stack, GCC might reset stack pointer during initialization, if it doesn't (find out if it does) then you can probably push and pop all of the static V-USB variables when jumping.
If that doesn't work, maybe you can be ballsy and allocate a block on the heap in your application code, and have the bootloader code find it. Basically make the application malloc and save a string in memory like "0000QWERTY" (note, you need to pad a few bytes before the letter "Q" depending on the static memory allocation differences between the bootloader code and the application code) followed by an array of bytes representing the V-USB static variables, and have the bootloader scan from null to where the letter Q starts, try and match the next "WERTY" (if no match, find next "Q"), if a match is found, then load the V-USB static variables with the array of bytes found after "QWERTY". This is an extremely stupid way of doing this though.
You can also try saving and loading the variables to/from eeprom, or external memory of some kind.
No guarantee that any of this will work, you are welcome to try for fun though.