1 Reply Latest reply on Dec 13, 2018 9:32 PM by SrinathS_16

    [FX3] Loading firmware image into RAM

      I've wrote a bootloader based on "Fx3BootAppGcc" example. I'm running it on CYUSB3KIT-003 and using the on-board EEPROM chip. My bootloader resides at I2C 0x0 and there is another firmware image elsewhere (0x2000) in the memory (both images are verified to be correct in I2C memory using external I2C memory programmer). With proper PMODE (I2C boot) FX3 boots correctly from I2C image at 0x0. I’m connecting the OCD/GDB via the on-board serial debugger at this point. My bootloader loads the image block by block, copied by 128 bit buffer just like the "Fx3BootAppGcc" example and as described in AN76405 (EZ-USB FX3/FX3S Boot Options). Each block reads RAM target address and length, until it encounters 0 length block, then it reads the program execution start address and the checksum. My bootloader does to the checksum calculation too and it does match the one at the end of image file.

       

      My problem is that when I try to copy the image data blocks into RAM using CyFx3BootMemCopy() I’m getting unexpected behavior. Most commonly my GDB keeps won’t do a step (it will just continue to step on a single instruction, with no loop there) after executing one step on CyFx3BootMemCopy (less commonly it will complete the copying but won’t hit another breakpoint, it will just stay in “running” state). Even when it does reach the CyFx3BootJumpToProgramEntry() it won’t boot properly (just keeps on “running”). The program that I’ trying to load to RAM is a small and simple BootLedBlink. It has just 2 sections, one targeting 0x40078000 (length 0x467) and the other one targeting 0x4007f000 (length 0x1e).

       

      Is it possible that I’m copying into the RAM region that is occupied by currently executed instructions by MCU and that’s causing the weird behavior?

       

      I’ve tried build both of those firmware with different i2cconf parameters passed to elf2img (0x0E, 0x0 etc), it had no effect.

       

      The space between the bootloader and the second image (in the I2C memory) is filled with 0xFF (don’t think it matters).

       

      Addressing the I2C pages” is not the issue, I’m fitting into first one with both bootloader and the second firmware, and the calculated checksum is identical, so the data is ok.

       

      The other strange thing is that when I’ve build the unmodified version of “Fx3BootAppGcc” with defines for I2C boot, uploaded a LedBlink image into 0x0 I2C memory, then the “Fx3BootAppGcc” into RAM using the USB Control Center application it failed the LedBlink example too.

       

      What could be wrong here? Is there a way to tell the elf2img to use different RAM addresses to avoid those potential conflicts? Or it’s not the issue here?

       

      Thanks,

      Matthew