FXLC95000 and hard reset

cancel
Showing results for 
Search instead for 
Did you mean: 

FXLC95000 and hard reset

Jump to solution
1,254 Views
vitaliysiplichu
Contributor III

Hello!

 

I can't reset my FXLC95000 via RESETB pin.

I have implemented one feature in my device recently. I added one more command for firmware version checking. That's how it works:
1. I power on my device

2. Send command 0x00 0x00 to be sure that there is fxlc95000 on I2C bus

3. Then send 0x29 0x00 to start

4. Then send my command for fw version checking

5. If I get not valid number of fw version I update fw.

 

So here is my problem:
If we have any fw in fxlc95000 then everything works perfect. I can compare fw version and make fw updating.

But! If we have fxlc95000 without firmware(from factory) or with damaged firmware(for example if we make power off during programming firmware) then when we try to send 0x29 0x00 we have 0xff 0xff answer. Then I understand that I need to update firmware but I can't do it because I have 0xff or 0x00 answer on my any commands. As I understand fxlc95000 is in undefined condition after my command 0x29 0x00 in that case.

I desided to make hard reset via RESETB pin and then update firmware without sending 0x29 0x00 command. But it doesn't help. I still have undefined condition of fxlc95000 after command 0x29 0x00 even if I make reset.

If I try to programm firmware without command 0x29 0x00 - everything works.

Because of that my feature does not make sense because we can have new fxlc95000 or with damaged firmware and I can't programm it in that case.

 

Here are my question:
Maybe there are some settings for hard reset or I should make strong time delays then i manipulate of RESETB pin???
Maybe there is another way to make reset fxlc95000 after sending 0x29 0x00 then there is no any firmware inside?

Maybe there is any way to find out is there available (unbroken) firmware inside without sending 0x29 0x00 command?

Labels (1)
Tags (2)
0 Kudos
1 Solution
451 Views
aswins
NXP Employee
NXP Employee

Hi Vitaliy,

                 I guess this would your problem.

From the below figure , (Page 228 in FXLC95000 Hardware Reference Manual), you can see that only on Power on Reset, FOPT[15:8] is initialized which has the BF (Boot to Flash bit).  For a factory device with erased flash, device will boot directly into the ROM command interpreter on power-up. This is because, on POR, BF bit is initialized to 0 which is the inverted bit of Bit 5 of address 0x01_FFFE.

pastedImage_0.png

So if you are trying to reset via only RESETB pin (not POR) after 0x29 0x00 0xFF 0xFF 0xFF 0xFF you will boot to flash immediately after reset as BF bit is set to 1. Hence any ROM command in this phase is not valid.

However if you do POR, since FOPT is initialized BF bit is set to 0 and now you are in ROM mode and any subsequent ROM commands become valid.

Hope this answers you question. Please refer the manual for additional details

Thanks

Aswin

View solution in original post

0 Kudos
7 Replies
451 Views
aswins
NXP Employee
NXP Employee

Hi Vitaliy,

              I think you are getting an error because there is not a valid image programmed in flash .  What is the stauts of your flash_opt (@0x1FFFC) register in your program? Are you sending the value 0x29 0x00 0xFF 0xFF 0xFF 0xFF to ROM CI to execute the flash?

Thanks

Aswin

0 Kudos
451 Views
vitaliysiplichu
Contributor III

Hi Aswin!

I'm glad to hear you again. I want to clarify my question.

You write: "I think you are getting an error because there is not a valid image programmed in flash ."

YES! That's what I'm talking about! It is possible in two situations:

1. We have a new fxlc95000 from factory (without any image in flash).

2. We have damaged image in flash (for example then we had power off during programming flash).

Problem is:

In those two situations then I send 0x29 0x00 0xFF 0xFF 0xFF 0xFF 0xFF command I have an error answer on that command and any other commands after that.

I try to make reset via RESETB pin to reboot it and send 0x00 0x00 again to get "good" answer. But there is no effect. I can get answer without errors only if I make Power OFF and Power ON again.

It seems to me that RESETB pin doesn't work if we have not valid image in flash. Is it true?

The question is:

How to reset fxlc95000 after sending 0x29 0x00 0xFF 0xFF 0xFF 0xFF 0xFF command if we have not valid image in flash?

0 Kudos
452 Views
aswins
NXP Employee
NXP Employee

Hi Vitaliy,

                 I guess this would your problem.

From the below figure , (Page 228 in FXLC95000 Hardware Reference Manual), you can see that only on Power on Reset, FOPT[15:8] is initialized which has the BF (Boot to Flash bit).  For a factory device with erased flash, device will boot directly into the ROM command interpreter on power-up. This is because, on POR, BF bit is initialized to 0 which is the inverted bit of Bit 5 of address 0x01_FFFE.

pastedImage_0.png

So if you are trying to reset via only RESETB pin (not POR) after 0x29 0x00 0xFF 0xFF 0xFF 0xFF you will boot to flash immediately after reset as BF bit is set to 1. Hence any ROM command in this phase is not valid.

However if you do POR, since FOPT is initialized BF bit is set to 0 and now you are in ROM mode and any subsequent ROM commands become valid.

Hope this answers you question. Please refer the manual for additional details

Thanks

Aswin

View solution in original post

0 Kudos
451 Views
vitaliysiplichu
Contributor III

Hi Aswin!

Thank you for your answer. This is what I've understood:

If we have blank flash memory or damaged flash then after sending 0x29 0x00 0xFF 0xFF 0xFF 0xFF and making reset via RESETB pin we will jump to flash memory. After that we will not have ability to send any command because there is not a valid image programmed in flash. So we need to make POWER OFF if we want to send any commands. Am I right?

I've found another way to find out do I need to update firmware - I check flash memory CRC and compare it with valid CRC. Then I make decision about firmware updating. Now it works for me. Everything is OK! It is more correct solution. Do you agree with me?

0 Kudos
451 Views
JackITB
NXP Employee
NXP Employee

Hi Vitaliy,

Let me jump into this thread as I'm supporting also the FXLC95000 device.

Yes the use of CRC check is definitively a good and robust solution.
There's actually a ROM Command Interpreter utility (cf CI_CRC command in HW ref manual §16.5.7) that can do the CRC computation job. Maybe you are using it already...

There's even a possibility to have the device do this CRC check at reset if you tweak the CHECKB bitfield of the NVBOPT Flash byte (address 0x01_FFFE). Then if the verification fails, the device will revert to ROM code. I didn't tried this feature as its documentation is rather scarce but if you're interested in using it, I can dig further.

As one of your verification step is to check the FW version, you can also do it from the ROM Command Interpreter, before sending the "boot to Flash" 0x29 0x00 command.
- dedicate a fixed Flash address to store the FW version, for example 0x01_FFF8, and define its content within your program code

- read the content of this address using the ROM CI_READ_WRITE command (HW ref manual §16.5.5)

command: 0x09 0xC4 0x0FF 0xFF 0xFF 0xFF FF F8 // Read 0x01_FFF8 to 0x01_FFFB content (4 bytes). No CI_PW needed if security is disabled

Thanks for your interest in our product.

Regards,     Jacques

451 Views
vitaliysiplichu
Contributor III

Hi jacques!

Thank you for your answer. It's a good advice about storing FW version in fixed Flash address. I will try it later because I have another tasks now.

How can I define address? Is this string enoght in code if I want to save version 101 for example? I use CodeWarrior and ISF1.0:

uint32 flash_opt @0x1FFF8 = 0x00010001;

After that when I power up device I can read four bytes using ROM CI_READ_WRITE command. Right?

0 Kudos
451 Views
JackITB
NXP Employee
NXP Employee

Absolutely,

But I suggest you use a different name than flash_opt...

For example, I tried the following:

uint32 flash_rev @0x1FFF8 = 0x01234567;

Then, build and Flash the binary.

Finally simple verification using FXLC95000 MailboxTool PC GUI

IIC WRITE TRANSACTION :: Starting MB = 00

  Write : 09 C8 00 00 00 00 FF F8 // Read 0x01FFF8-0x01FFFF content (no PWD needed as security is disabled)

IIC READ TRANSACTION :: Starting MB = 00, No. bytes to read = 10

  Read  : 09 80 01 23 45 67 FF FF FF FF