LUFA bootloader API woes

[inizen]

Hi there:

I have been experimenting with calling into the LUFA DFU bootloader from my application via the jump table (BootloaderAPITable.S) that seems to be included for that purpose. I want to write some self-modifying code. So far I have encountered two problems, one of which I think I have solved. Help with the other would be *massively* appreciated.

Problemo Uno

As per the documentation I found in the Doxygen file BootloaderDFU.txt I created a bunch of function pointers initialised to point to the LUFA DFU bootloader jump table. I'm running on an AT90USBKEY. The documented calculation for these pointers seemed wrong (to me) and didn't return correct values. So I tweaked them to:

#define BOOTLOADER_API_START(Index)        (void*)(((FLASHEND - 31) + (2 * Index)) / 2)

void    (*BootloaderAPI_ErasePage)(uint32_t Address)               = BOOTLOADER_API_START(0);
void    (*BootloaderAPI_WritePage)(uint32_t Address)               = BOOTLOADER_API_START(1);
void    (*BootloaderAPI_FillWord)(uint32_t Address, uint16_t Word) = BOOTLOADER_API_START(2);
uint8_t (*BootloaderAPI_ReadSignature)(uint16_t Address)           = BOOTLOADER_API_START(3);
uint8_t (*BootloaderAPI_ReadFuse)(uint16_t Address)                = BOOTLOADER_API_START(4);
uint8_t (*BootloaderAPI_ReadLock)(void)                            = BOOTLOADER_API_START(5);
void    (*BootloaderAPI_WriteLock)(uint8_t LockBits)               = BOOTLOADER_API_START(6);

#define BOOTLOADER_SIG_START               (FLASHEND - 1)
#define BOOTLOADER_SIGNATURE               0xDCFB

These tweaks improved things and I was able to read all the fuses and lock bits correctly.

Problemo Duo

So I moved on to trying to write a page of program flash memory, using the following app code:

    :
BootloaderAPI_ErasePage(0x4e20);
BootloaderAPI_FillWord(0x4e20, 0x1234);
BootloaderAPI_WritePage(0x4e20);
    :

The 0x4e20 is chosen at random to be mid-memory (away from the little test application and boot section). I program the bootloader using AvrStudio JTAG then the app using Flip, but when I run the app now it seems to erase all the program flash (but not the bootloader) when I thought this would at most affect a single page.

HELP! Please :)

Martin

[Dean Camera]

Martin,

You are indeed correct, and the latest official release has a bug in the bootloader API address calculation example, which has since been corrected in the latest trunk:

www.lufa-lib.org/latest-archive

Also corrected in the latest trunk is some alignment issues that was causing the various bootloader API sections to wander around for some reason, which I've fixed by individually locating each sub-section of the API section. I'd suggest updating to use that version of the bootloader if possible.


The second problem is a bit interesting; the API routines are just thin wrappers around the bootloader functions provided by avr-libc, and used by the bootloader itself. My guess is that the issue is that your page address isn't aligned to SPM_PAGESIZE - if it is unaligned, bad things will happen when you feed that to the device as the page address. Try using a multiple of SPM_PAGESIZE (typically 128 or 256 bytes) as your page address when calling the page erase and page write functions.

Cheers!
- Dean

[inizen]

Hi Dean:

Thanks for your prompt response. I've downloaded your latest archive but come to a screeching halt. Before I had kind of figured out how to modify your makefiles to build on Windows, but now they look a bit more complicated and leverage quite a few Unix utilities. Is there some way to set up a Unix like make environment on Windows?

Regards,

Martin

[Dean Camera]

Martin,

The new build system is optional - you can copy-paste the makefiles from an older release and they should work just fine in most cases, the exception being the bootloaders due to the changes in the sections being relocated (although you can backport these if you wish). The underlying system is very similar to the sections of the old makefile, so if you have some juju that will allow an old makefile to compile without a set of unix tools being present, you can modify the central modules in LUFA/Build/*.in to get the same effect.

That said, the new system is designed to be much easier than the old, since most people only modify a very small set of options and not the actual makefile rules themselves. To get a build system up and running, all you need to do is *either* have the last WinAVR toolchain release installed and the WinAVR/utils/bin/ directory in your path, *or* download and install the "basic" system package of the of the MinGW installer from http://www.mingw.org. Once installed, add the "msys\1.0\bin" of the MinGW installation folder is added to your system's PATH environment variable. If you also want to compile the bootloaders, you'll need the bc utility from http://gnuwin32.sourceforge.net/downlinks/bc.php . I've added new sections to the documentation (run "make doxygen" in the LUFA core folder to regenerate it) explaining the build system, the new makefile templates, and the prerequisites.

Cheers!
- Dean

[inizen]

Hi Dean:

Thanks again for your prompt reply. I installed MSYS and BC and built your new LUFA bootloader, but now Windows 7 64-bit is not detecting the AT90USBKEY via the USB port. It doesn't detect anything for the original Atmel DFU bootloader (I cannot remember where I obtained that) or the new LUFA library, but does detect the old (LUFA-120219) bootloader, although in that case it says it's working incorrectly until I upgrade the driver to the one in the FLIP USB folder. Then it works but Windows still fails to detect the Atmel or new LUFA bootloader.

Frustrating :( Any ideas?

Martin

p.s. The new LUFA bootloader sits there with a steady red LED.

[Dean Camera]

My guess is that the fuses are set for a different sized bootloader section. Previous LUFA releases had the bootloader section set to the smallest values possible for each bootloader (4KB for DFU and CDC, 2KB for HID) but this caused quite a lot of support requests on it. Consequently, I've adjusted it to be 8KB for all bootloaders, so that it will run as-is on the USBKEY as shipped.

If you can run an earlier LUFA bootloader, your device's fuses are probably set for a 4KB bootloader section (2K words). Either adjust the bootloader makefile bootloader size for a 4KB section and recompile, or change your device's fuses.

- Dean

[inizen]

Hi Dean:

Thanks. I should have spotted the changed bootloader section size (but I missed it in the spots before my eyes :). But even setting it correctly didn't get me much further. After some debugging I think you still have problems in your bootloader API. Here are my suggested fixes (which worked for me). In a couple of your bootloader API functions you need to insert a boot_spm_busy_wait() after the operation and before the boot_rww_enable(). Using the boot_page_xxx_safe() functions waits for SPM to be done BEFORE the operation but not after. You need to wait for the SPM again, before reactivating the RWW section, otherwise dreadful things happen. See below for suggested changes:

void BootloaderAPI_ErasePage(const uint32_t Address)
{
    boot_page_erase_safe(Address);
    boot_spm_busy_wait();
    boot_rww_enable();
}

void BootloaderAPI_WritePage(const uint32_t Address)
{
    boot_page_write_safe(Address);
    boot_spm_busy_wait();
    boot_rww_enable();
}

In your documentation the calculation

#define BOOTLOADER_API_TABLE_SIZE          32

needs to be replaced with

#define BOOTLOADER_API_TABLE_SIZE          40

[Dean Camera]

Martin,

Quite right, I had a fuzzy recollection that there wasn't a "safe" version of the RWW enable macros, but apparently there is - I am indeed missing the SPM busy wait before re-enabling the RWW section.

As for the section offsets, these are a transcription error with the move to the new build system; they are supposed to be located at 96, 32 and 8 bytes from the end absolute, and not relative to each other (thus the API offset in the header file example is correct, and the makefile for the bootloaders is wrong).

I'll patch these issues in the repository, sorry for the trouble! What name should I use for the credit in the changelog?

Cheers!
- Dean

[Martin Lambert]

Hi Dean,

You're very generous :) My name is Martin Lambert. When do you think the patch will make it into your public published version?

Regards,

Martin

--
You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
To view this discussion on the web visit https://groups.google.com/d/msg/lufa-support/-/ZhAZQJqr-oAJ.
To post to this group, send email to lufa-s...@googlegroups.com.
To unsubscribe from this group, send email to lufa-support...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lufa-support?hl=en.

[Dean Camera]

Thanks Martin! The fix is in the repository.

I was hoping to put off the next release until I had refactored enough to have some demos for the highly experimental UC3 and XMEGA platforms, but that is becoming less and less likely to be completed soon due to the amount of work involved in fixing up the board system and demos. As a result, I might push out the latest trunk as a beta of the next release during the week, so that everyone will have a new stable base to work with while I complete the additional modifications needed for multi-arch demo support.

Cheers!
- Dean

On Friday, June 29, 2012 12:41:38 AM UTC+2, inizen wrote:

Hi Dean,

You're very generous :) My name is Martin Lambert. When do you think the patch will make it into your public published version?

Regards,

Martin

To unsubscribe from this group, send email to lufa-support+unsubscribe@googlegroups.com.