Please use the CyU3PDeviceReset() API with the isWarmReset parameter set to CyTrue. In this case, the firmware starts executing from the beginning and the global variables are re-initialized. Kindly, test this and let us know if the data is still corrupted.
I have tried the API command CyU3PDeviceReset() with the isWarmReset parameter set to CyFalse, this will restore the data from our device.
I have also used the following link to test the reset command:
But my problem is that the CyU3PDeviceReset causes the device to disconnect from the PC, this is what i dont want to happen.
Due to the PC software having to re-open the device again.
We also use a second-stage bootloader so should we be jumping back to to the bootloader before trying to use CyU3PDeviceReset?
We have also a simple vendor command in the second-stage bootloader that will return a character "B" when requested.
When we are getting corrupt data, we can jump to the bootloader and its simple vendor command will give the expected data.
- Please let me know what is the boot option used in you second stage boot-loader?
- Are the descriptors that are used in the second stage boot-loader and the main application firmware the same?
- Are you setting the noReEnum parameter to CyTrue in the CyFx3BootUsbStart() API?
- When the noReEnum parameter is set to CyTrue and the firmware is loaded, there will be no re-enumeration but the firmware will be re-loaded and will start execution from the entry point. So, in case of data corruption, you can jump to second stage boot-loader (which sets the noReEnum parameter to CyTrue) and load the new application firmware.
the boot option is set as i2c with usb fallback
yes the descripters are the same for the second-stage boot loader and application code
yes the noReEnum parameter is set to CyTrue in the CyFx3BootUsbStart() API
sorry Im not following your last sentence.
During normal operation our code goes from second-stage bootloader to the application code this can be checked by the simple vendor commands added to both projects to return an "A" or a "B" character.
Normally this jump feature is only used when we want to upgrade the application code with products in the field, so it shouldnt be used.
I had only mentioned it as i wasnt sure if the CyU3PDeviceReset() API would need to be called from the boot code or the application code.
Are you suggesting that we jump to the boot code and try to upload a new application to RAM? If so will this not also cause a re-emumeration?
Please see the below sequence.
- Data corruption is observed.
- A jump to the second stage boot-loader is performed.
(Ensure that the second stage boot-loader has got the option to load firmware into the RAM through USB with noReEnum parameter set to CyTrue)
- The main application firmware is loaded.
- No re-enumeration will be observed since the noReEnum is set to CyTrue.
- Perform vendor commands.
Kindly, test the above sequence and let me know the observation.
During normal operation we store a merged second-stage bootloader and application code in the i2c eeprom, on power up the second-stage bootloader is executed which jumps to the application code.
After striking the device our software stops communicating to the device due to data corruption.
Ideally we would want a way to recover the corruption here without having the device from having to re-enumerate.
To determine if data corruption is only on data going out of the FX3 to the pc or in both directions i've sent vendor commands that should return known data. I can see that it appears to only be on data from the FX3 that is corrupt. Data getting sent to the FX3 seems to pass through correctly.
This is also when i tested trying to jump back the the bootloader code to check if it is also corrupted, which doesnt appear to be.
Our problem with the above sequence would be that the main application code would have to live on the PC and get loaded when an esd strike occurs.
What we are currently trying to add is a vendor command into the bootloader to allow jumping from the bootloader into the application code again to see it this will resume communications again.
which so far we have had no luck.
I will also try to an application that can upload a version of the application code to the device, i can use the cypress control cender due to having to swap drivers which would cause the device to disconnect.
we were able to perform the steps that you have mentioned above:
we got the FX3 into the corrupt state, jumped to the second stage bootloader and using a custom application we uploaded the main application again. No renumerations was observed.
I modified our application code to know that it has started, and performed a vendor command that give access to the eeprom where the fx3 code is stored, on writing into the eeprom with a known string then reading this data out again i have to peform multiple read accesses before i start to get the correct information out.
In a non-corrupt state i only need to perform one read access to get the required data, this data corruption seems to be for is to both an FPGA and eeprom both of which are connected to the FX3 over I2C.
Is there any other options i could try?
Please check if the I2C block was stopped before jumping to the second stage boot-loader. All the blocks that were running in the firmware need to be stopped before jumping to the second stage boot-loader.
Below is our jump to bootloader code which will stop the i2c block.
case Jump_Boot:/* Request to switch control back to the boot firmware. */
AppStop(); // reset endpoints/destroys DMA channels
which should be resetting the i2c block, would there be any other blocks i would have to reset?
- The CyU3PI2cDeInit() API is sufficient to stop the I2C block.
Can you please probe the I2C lines during the corrupt data that is being read on the host? This would help us identify if the corrupt data is from the FX3 DMA buffers or is it because of some data corruption in the EEPROM.
we will need to check if this is possible, due to having the product enclosed. Im not sure if we are able to open the casing while the power is still on.
I will have a look and get back.
We were able to get a way of monitoring the i2c bus after corruption has occurred.
we have loaded two messages into the eeprom:
"Hello world first message" and "Second message in the eeprom"
After powering up the device and reading out the two strings we get the correct strings back.
After getting the FX3 into the corrupt state and then asking for the same strings back we get:
shown in HEX:"0x55,0x33,0x56,0x43,0x03,0x80,0x01,0x08,0x00,0x00,0x01,0x08,0x01,0x00,0x00,0x00,0x0C,0x00,0x00,0x00,0x00"
and "o woHellfirstld ssagt me<null><null><null><null>"
The i2c track shows the same trace in the corrupt and non-corrupt state being read out of the i2c eeprom so there is no corruption on the eeprom side.
Please share the main application firmware and the second stage boot-loader firmware source code. If it is confidential, please share over the private message option.
private message has been sent.