FX3 Second Stage boot loader issue

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
PrM_1403381
Level 4
Level 4
First like received First like given Welcome!

Hi,

I am using Cypress FX3 in my design, and I am planning to use SSBL to update the application FW, So I referred FX3 Fail Safe Firmware Update link to understand about the FW update.

And followed the instructions provided in the above mentioned link.

1. I am using USB control Ep communication to update the FW to I2C EEPROM

As per my understanding FSBL will boot from BootROM and SSBL will be loaded into SRAM from I2C EEPROM address 0x000000, and SSBL will be running, I kept a condition in SSBL that it will check for the value at the EEPROM address 0xFFFC,

-> If the value is 0xA555AA5A(BOOT_MODE) Jump to actual application FW,

-> If the value is 0xFAAA55AF(PGM_MODE) stay in SSBL, This will be used to update the actual FW into EEPROM address 0x8000,

I made changes to the boot source Project "Fx3BootAppGcc_Project" As per the instructions provided in the above mentioned link. And as well changes are made in Cypress fail safe FW update utility also. Please find the attached Boot loader Source code and as well as C# utility.

Issue : SSBL is loading successfully, And using the C# utility to update the actual FW, And able to change the mode to boot mode, But When SSBL start loading the application FW, At the end CyFx3BootJumpToProgramEntry (secAddress); secAddress is becoming 0x00, and the same bootloader application running always, I tried running SSBL in debug mode and found this behavior, Please help me out in finding the root cause.

I have attached the Source code for my SSBL Bootloader FW, and the C# utility I am using

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.

Hi Yatheesh,

When I read back the EEPROM data, last chunk of data was not written. Made some changes to the C# utility and it works fine as expected.

Actually I will be writing 128 bytes of data in each time and after update I am able to boot, If I use USB 2.0 cable or if FX3 is connected to USB 2.0 port, then Control EP max bytecount will be 64 only, SO I amde changes in C# utility to send 64 bytes of chunk at a time, and the bootloader I kept the same as old, And it is not working. So for USB 2.0 cable/USB 2.0 Port how can be handled ? Attached C# utility for reference

1. Fx3FirmwareUpdate is with 128 bytes

2. Fx3FirmwareUpdate1 is with 64 bytes

Do I need to make any changes in FX3 Second stage bootloader Firmware also ??

Best Regards,

Prasanna

View solution in original post

0 Likes
16 Replies
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

According to my understanding, you could successfully update the firmware in the EEPROM location 0x8000. Also, you were able to successfully switch to boot mode after this update. Please correct me if Iam wrong.

Please let us know if any of the APIs are failing while booting. You can do this by using the API CyFx3BootDeviceReset ();. Please try this and let us know the result.

Best Regards,

Jayakrishna

Best Regards,
Jayakrishna
0 Likes

Hi Jayakrishna,

Yes, I am able to update the FW from EEPROM location 0x8000, ANd in Flash Program command I also verified by using read and compared the written and read back data during each 128 byte data writing, If any mismatch in written and read back data I set one GPIO to high. So the data written is successful to the EEPROM.

Yes switching between Boot mode and Program mode also happening,

I was following below sequence while updating the FW

1. Update the Actual Application FW using cypress control center

2. Set the SSBL to the Program Mode by using 0xF3

3. Update the SSBL using cypress control center

4. Again update the application FW using the attached utility in my previous comment, Now FW update will be done from the 0x8000

5. After FW update, reset the device using 0xF5

6. Change the SSBL to boot mode using 0xF2

7. Read back the mode using 0xF1 and i will get the data : A5 55 AA 5A, And this is proper.

You asked to try any of the API is failing while booting, I ran SSBL in debug mode, Capture.JPG

By the time when SecLength == 0, secAddress was also coming 0, So again the SSBL was running,

NOTE : But I observed one strange behavior, If I skip the step no 5, In step 7 the return data was 5A A5 55 AA

Thanks & Regards

Prasanna

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Prasanna,

Regarding the steps you mentioned:

1. Update the Actual Application FW using cypress control center -> Please elaborate. Do you choose program EEPROM? And then do you choose Application firmware image to program?

2. Set the SSBL to the Program Mode by using 0xF3 -> How is SSBL running at this step?

3. Update the SSBL using cypress control center  -> Do you program new SSBL firmware into EEPROM here?

4. Again update the application FW using the attached utility in my previous comment, Now FW update will be done from the 0x8000

5. After FW update, reset the device using 0xF5

6. Change the SSBL to boot mode using 0xF2

7. Read back the mode using 0xF1 and i will get the data : A5 55 AA 5A, And this is proper.

Please let me know the above.

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,

Please find my comments below:

Regarding the steps you mentioned:

1. Update the Actual Application FW using cypress control center -> Please elaborate. Do you choose program EEPROM? And then do you choose Application firmware image to program?

     [Prasanna] - Yes, I will update the application to EEPROM using Cypress bootloader,

     In Control Center, Program --> FX3 --> I2C EEPROM and then select the application FW img file, Ex : bulksrccnk.img

     After successful updating of FW, remove the PMOD jumper and my application will boot, FW is updated just to confirm If I update my FW      using cypress bootloader will this boot properly or not. So It is booting properly

2. Set the SSBL to the Program Mode by using 0xF3 -> How is SSBL running at this step?

     OK, This might be confused.

     [Prasanna] - Actually, In this step my application FW will be running not the SSBL,

     In SSBL I am differentiating boot mode or program mode based on the data read from EEPROM address 0xFFFC, Just to make sure after      updating SSBL, It should remain in program mode, I am setting the 0xFFFC address with PGM Mode while application FW is running

3. Update the SSBL using cypress control center  -> Do you program new SSBL firmware into EEPROM here?

     [Prasanna] - Yes, Now again I will short the PMOD jumper, and update the SSBL FW to the EEPROM

     In Control Center, Program --> FX3 --> I2C EEPROM and then select the application FW img file, Ex : USB_Bootloader.img

     After successful SSBL FW update, remove PMOD jumper, and boot the FX3.

4. Again update the application FW using the attached utility in my previous comment, Now FW update will be done from the 0x8000

     [Prasanna] - Now, SSBL will be booted and it is running, I can differentiate PID of application FW and SSBL FW, So Now EEPROM contains only SSBL FW and SSBL is running.

     So, I will use the utility to update the application FW, This application FW will be updated to the EEPROM at the address      0x8000(EEPROM)

5. After FW update, reset the device using 0xF5

6. Change the SSBL to boot mode using 0xF2

     [Prasanna] - In SSBL also I can differentiate whether it is boot mode/program mode like in FSBL PMODE pin is used, But in SSBL I am using the data from EEPROM address 0xFFFC, based on this data, SSBL enter to booting, Means it will start reading the data from EEPROM address 0x8000, based on SecLength and address and keep it in SRAM, and it will jump to the application FW

7. Read back the mode using 0xF1 and i will get the data : A5 55 AA 5A, And this is proper.

     [Prasanna] - means this data is read from EEPROM address 0xFFFC address,

Please let me know if any input is needed.

Thanks & Regards,

Prasanna

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Prasanna,

Please try this quick test:

When SSBL is running, use your updated utility to program the EEPROM from 0x0000. Then change the PMODE to I2c Boot and reset the device. Check if the boot is proper.

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,

I tried the method that you suggested, While SSBL running, I used used the C# utility and updated the application FW to EEPROM at the address 0x0000, So it will overwrite SSBL, and the application FW should boot(If my understanding is correct about your suggested experiment ?), But it didn't boot. It stays in FSBL only.

So, our write is not happening properly to I2C EEPROM ?

--> I verified write and read from the eeprom and compared the data, If any data mismatch between written and read data of 128 byte chunk at iteration I was set one GPIO to high, So I think EEPROM writing can't be a problem.

Any suggestions ?

Thanks & Regards

Prasanna

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Prasanna,

Yes. You are correct. I wanted to see if the utility is updating the EEPROM correctly. I note that you are writing and reading the EEPROM content while programming it.

But looks like there is some problem. After programming, perform a reset, and just read out the content of the EEPROM and compare the data with some Hex editor. That would confirm if there is some problem.

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,

Thanks for you suggestion, I will verify that and let you know the outcome.

Have you gone through the attached SSBL Source code and attached C# utility, Have you found any thing suspicious in the code.

As per your suggestion, if I read back the data and compared and if there is difference, What could be the reason ? Any idea ?

Best Regards,

Prasanna

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

I have gone through the files. But didn't see any issue as of now. I will update if I see any.

There is no difference in what we are trying but we can come to know if there is any corner case quickly.

Regards,

Hemanth

Hemanth
0 Likes

Thanks, I will Read back the data and compare, I will share the outcome.

Best Regards,

Prasanna

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Yatheesh,

When I read back the EEPROM data, last chunk of data was not written. Made some changes to the C# utility and it works fine as expected.

Actually I will be writing 128 bytes of data in each time and after update I am able to boot, If I use USB 2.0 cable or if FX3 is connected to USB 2.0 port, then Control EP max bytecount will be 64 only, SO I amde changes in C# utility to send 64 bytes of chunk at a time, and the bootloader I kept the same as old, And it is not working. So for USB 2.0 cable/USB 2.0 Port how can be handled ? Attached C# utility for reference

1. Fx3FirmwareUpdate is with 128 bytes

2. Fx3FirmwareUpdate1 is with 64 bytes

Do I need to make any changes in FX3 Second stage bootloader Firmware also ??

Best Regards,

Prasanna

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Prasanna,

So, currently when SSBL is enumerated as 3.0 everything is fine but you have issues with 2.0 Am I correct?

And when in 2.0, you write 64 byte chunk into the EEPROM at once.

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,

Yes you are right,

Yes when 2.0 I will write  64 bytes over control EP, and SSBL remained same, While loading the FW from EEPROM, It will be reading 128 bytes continuously from the EEPROM as per Sec address and SecLength.

Best Regards,

Prasanna

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Prasanna,

It is correct that control endpoint size is 64 bytes. But you need not call XferData() with 64 bytes at once. You can still keep it at 128 bytes. The Host controller will send the packets with maximum of 64 bytes at once i.e the data phase of control transfer in the case of usb 2.0 will be 2 64 byte packets when wLength is 128. So, please try with 128 bytes itself and verify the EEPROM content is as expected.

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,

Thanks, I will check this and update.

Best Regards,

Prasanna

0 Likes

Hi Hemanth,

Thanks for the input. Yes it is working with the above mentioned method.

Best Regards,

Prasanna

0 Likes