11 posts / 0 new
Author
Message

Hello everyone!

I am running my application and the Mass Storage bootloader (LUFA) using atmega32u4…

Everything is working fine.

My question would be: Is it possible to send a byte to the uC through a terminal (HTerm for example) when running on bootloader mode?

I know there are other ways to do that, but this is the way it suits better for my application.

Thank you very much for the tips!

Terminal implies CDC-ACM. So you'd need to make the bootloader a dual class device enumerating as both MSD and CDC-ACM.

To be honest I don't really follow the requirement. Surely you start into the bootloader and once firmware.bin (or whatever) is written you then jump to the app. Why would you need a separate trigger? But if you did why not fake another file called something like "OK.GO" and when you see that written (with anything) you jump to the app space anyway whether a new firmware has been delivered or not?

“Surely you start into the bootloader and once firmware.bin (or whatever) is written you then jump to the app.”

Exactly! And how the uC knows when the new firmware *.bin was written? Is there an event that is fired? Because right now, when I replace the bin file, nothing happens… And I can check that the app was replaced… but it doesn’t jump to the app automatically… How could I do that then?

When the new firmware *.bin was written? Is there an event that is fired?

What on earth are you talking about? That's surely the whole point of Dean's bootloader? When it sees data written to the "sectors" of FIRMWARE.BIN it SPMs it into the flat so,  of course, it knows when that is complete.

If nothing is happening in your case I'd use your debugger to determine that the file data is really arriving. If no debugger add UART/LCD output or some other diagnostic aid.

Ok, so you are saying that the bootloader jumps to the app automatically after the bin file is updated? As this is not happening here, I thought that I should write this somehow in the code, like asm("jmp 0000");

If it should jump automatically, something is wrong, because I am sure I am updating the bin file (my app)…

Previously, you mentioned that I should use the Command prompt copy rather than using GUI drag/drop… Is this may be the reason why the uC is not jumping to the app? Why does that make so much difference? Why wouldn't it recognize that the bin file was updated?

Last Edited: Mon. May 4, 2015 - 12:58 PM

Hello again,

So, I used the Command prompt copy, instead of drag/drop… it didn’t make any difference… After I replace the bin file, the bootloader is still not jumping to application…

What should happen in the code when the file is replaced? To where the code should jump?

Thank you very much again!

Have you contacted Dean? He is active as @abcminiuser on twitter.

Ok, I will try to contact him… I thought he was also active here at avrfreaks…

Thanks again!

BTW, I forgot to mention something that I think it is important. I cannot use an external push button to reset the uC. It has to be done automatically by the software. After the bin file is replaced, jump to application.

When I reset the uC via external HW, it works! It’s jumping to the application. But I would like to do it automatically via SW.

You probably want to look at the logic here then:

/** Special startup routine to check if the bootloader was started via a watchdog reset, and if the magic application
*  start key has been loaded into \ref MagicBootKey. If the bootloader started via the watchdog and the key is valid,
*  this will force the user application to start via a software jump.
*/
void Application_Jump_Check(void)
{
bool JumpToApplication = false;

#if (BOARD == BOARD_LEONARDO)
/* Enable pull-up on the IO13 pin so we can use it to select the mode */
PORTC |=  (1 << 7);
Delay_MS(10);

/* If IO13 is not jumpered to ground, start the user application instead */
JumpToApplication |= ((PINC & (1 << 7)) != 0);

/* Disable pull-up after the check has completed */
PORTC &= ~(1 << 7);
#elif ((BOARD == BOARD_XPLAIN) || (BOARD == BOARD_XPLAIN_REV1))
/* Disable JTAG debugging */
JTAG_DISABLE();

/* Enable pull-up on the JTAG TCK pin so we can use it to select the mode */
PORTF |= (1 << 4);
Delay_MS(10);

/* If the TCK pin is not jumpered to ground, start the user application instead */
JumpToApplication |= ((PINF & (1 << 4)) != 0);

/* Re-enable JTAG debugging */
JTAG_ENABLE();
#endif

/* If the reset source was the bootloader and the key is correct, clear it and jump to the application */
if ((MCUSR & (1 << WDRF)) && (MagicBootKey == MAGIC_BOOT_KEY))
{
MagicBootKey      = 0;
JumpToApplication = true;
}

if (JumpToApplication)
{
// cppcheck-suppress constStatement
((void (*)(void))0x0000)();
}
}


also notice this in Lib/SCSI.c:

                case SCSI_CMD_START_STOP_UNIT:
#if !defined(NO_APP_START_ON_EJECT)
/* If the user ejected the volume, signal bootloader exit at next opportunity. */
RunBootloader = ((MSInterfaceInfo->State.CommandBlock.SCSICommandData[4] & 0x03) != 0x02);
#endif


FYI, NO_APP_START_ON_EJECT is defined in Config/AppConfig.h but by default that file contains:

#ifndef _APP_CONFIG_H_
#define _APP_CONFIG_H_

//      #define NO_APP_START_ON_EJECT

#endif


So by default that code in SCSI.c is built. That means that "ejecting" the USb device should trigger the thing.

Last Edited: Tue. May 5, 2015 - 01:43 PM

Yes, I was already looking to this part of the code and I also saw that when I eject the USB device, it also works (jump to app).

But this is still not what I am looking for… I would like to be done directly through software. When the bin file is replaced, no extra clicks or push buttons necessary…

Maybe I am asking too much, but I think there is a way to do that… I have just not found yet :/

That’s why I am here asking the experts :)