- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All
We have a control system with Coldfire processors remotely programming PSoC5LP devices.
The hardware layer is RS485 over a twisted pair, braided shield (earthed), of up to several metres in length. There are numerous installations worldwide with very sound operation.
For one installation the update of the PSoC is failing. This may be a hardware fault in one of the connections however it highlighted that there appears to be no communications timeout when the row programming is called (CyBtldr_ProgramRow). Therefore the host ends up hanging while trying to program the PSoC.
For the Erase Row call, ERR_COMM is listed as a return.
/*******************************************************************************
* Function Name: CyBtldr_EraseRow
********************************************************************************
* Summary:
* Erases a single row of flash data from the device.
*
* Parameters:
* arrayID – The flash array that is to have a row erased
* rowNum – The row number within the array that is to be erased
*
* Returns:
* CYRET_SUCCESS - The row was erased successfully
* CYRET_ERR_LENGTH - The result packet does not have enough data
* CYRET_ERR_DATA - The result packet does not contain valid data
* CYRET_ERR_ARRAY - The array is not valid for programming
* CYRET_ERR_ROW - The array/row number is not valid for programming
* CYRET_ERR_BTLDR - The bootloader experienced an error
* CYRET_ERR_COMM - There was a communication error talking to the device
* CYRET_ERR_ACTIVE - The application is currently marked as active
For the Program Row call there is no similar return. From debug on the Host device this appears to be the call which is hanging.
/*******************************************************************************
* Function Name: CyBtldr_ProgramRow
********************************************************************************
* Summary:
* Sends a single row of data to the bootloader to be programmed into flash
*
* Parameters:
* arrayID – The flash array that is to be reprogrammed
* rowNum – The row number within the array that is to be reprogrammed
* buf – The buffer of data to program into the devices flash
* size – The number of bytes in data that need to be sent to the bootloader
*
* Returns:
* CYRET_SUCCESS - The row was programmed successfully
* CYRET_ERR_LENGTH - The result packet does not have enough data
* CYRET_ERR_DATA - The result packet does not contain valid data
* CYRET_ERR_ARRAY - The array is not valid for programming
* CYRET_ERR_ROW - The array/row number is not valid for programming
* CYRET_ERR_BTLDR - The bootloader experienced an error
* CYRET_ERR_ACTIVE - The application is currently marked as active
Anyone have experience with a similar experience programming the PSoC from an external micro or similar device?
Thanks in advance
Greg
Solved! Go to Solution.
- Labels:
-
PSoC 5 Device Programming
-
PSoC 5LP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
CyBtldr_ProgramRow function sends a single row of data to the bootloader to be programmed into flash. Inside this function, CyBtldr_TransferData is responsible for transferring a buffer of data to the target device and later reading a response packet back from the device. CyBtldr_TransferData returns CYRET_ERR_COMM in case of any communication error talking to the device.
if (CYRET_SUCCESS != status)
err = status | CYRET_ERR_BTLDR_MASK;
Later, CyBtldr_ProgramRow is expected to return this error. Please let us know if you observe the same.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please clarify if you are using Bootloading or HSSP to update the firmware because the screeshots seem to be using Bootloader APIs. Bootloading and HSSP differ in the following key aspects:
- Bootloaders are used to update the flash memory of the device over a standard communication protocol. Bootloaders can update only a specific portion of the flash memory, known as the bootloadable area.
- On the other hand, HSSP supports complete programming of the flash memory in PSoC.
- Bootloaders can use any standard communication interface (such as, USB, I2C, SPI, and UART) to update the firmware, while HSSP uses an SWD or JTAG interface to program the flash. This application note project supports only SWD interface
To understand how you can use HSSP to program PSoC5 using an external microcontroller please refer to this application note. Please attach your project to get more insight on the issue you are facing.
Regards,
Dheeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Dheeraj
Sorry my mistake, to clarify it is Bootloading only.
The Host uses the Cypress API's as you noted in your email. The Target (PSoC5) is configured as bootloader with dual application (classic). Relevant screenshots or code snippets can be provided (firmware is proprietary). The Cypress API's on the Host are unmodified.
Please let me know if you have any thoughts or comments.
Regards
Greg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Dheeraj
Any further thoughts or would this warrant creation of a support ticket?
Regards
Greg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
CyBtldr_ProgramRow sends flash row data to target in smaller packets using send data commands. With the last piece of data, the host sends program row command to program the device flash row. Flash row write can take up to 20ms. Refer to Flash AC Specifications in device datasheet for more details. To guarantee data integrity during flash write, PSoC enters critical section during flash write. In critical section, none of the interrupts will be serviced and the communication interface might appear non-responsive/hanging. Please let us know whether the communication interface becomes responsive after device flash write completion. You can try to program single flash row from host and check whether the communication interface becomes responsive after flash write.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Geona
Appreciate your reply.
This issue can occur at anytime the our Host (Coldfire running CyBtldr API's) is sending data to the PSoC across the RS485 connection.
If the RS485 communication is momentarily interrupted and CyBtldr_ProgramRow does not receive a reply after sending the command, what would you theorize is the result on the programming operation? Could the Host ever recover?
The operation is recoverable as the PSoC has a Golden application, however recovering the Host is somewhat different.
Thank you in advance
Greg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Golden Image bootloader skips updating certain flash rows. Could you please share the communication log in both failing and recovering scenarios? This will help us to review the bootloader command and response packets and get more insights regarding the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Geona
There is no scenario where this process recovers; the PSoC either is programmed or communications is interrupted and not programmed.
Attached are two files with debugging switched on. This also includes part of our CLI for our product interface.
Regards
Greg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Geona
Any further comments on this item?
Regards
Greg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Greg,
Can you please confirm if there is a way to prevent the interrupts from occurring from the Host side (in the control system with Coldfire processor) just like the enter critical section on the PSoC side.
Regards
Ekta
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Ekta,
Certainly we could look at suspending all maskable interrupts in the Coldfire however the issue appears to be with the Cypress API's not recovering from a dropped packet during 'programming' of the PSoC Bootloadable application. Any thoughts or comments?
Kind regards
Greg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Cypress
As we are unable to raise a Case for this issue, how do we prevent this post from becoming necroed?
Is there any merit for the functionality of CYRET_ERR_COMM being added to CtBtldr_ProgramRow?
Any relevant comments appreciated.
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Cypress Bootloader protocol is implemented as a command-status register interface. For each command send from the bootloader host, there are response/status from the target bootloader component over communication interface. Previously shared log shows that Process PSoC rows data is getting stuck. However, the last response from the bootloader is not clear. Could you share the communication log in the failing and recovering scenarios (along with steps to recover) to get more insights on this issue? The commands would look like following host-target communication diagram;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Genoa thank you again for a reply.
We understand there 'can' be a response from the target bootloader component over communication interface.
If the Program Row Command across the physical layer (RS485) is interrupted, drop a byte, random electrical noise, consider any action where this command is not accepted or seen by the Bootloader, there will be no response from the target.
With no response from the Bootloader, does this result in the Cypress API waiting in ProgramRow forever? If the CYRET_ERR_COMM flag is not available to check for a timeout, is there another flag the host can check to exit this state?
Kind regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
CyBtldr_ProgramRow function sends a single row of data to the bootloader to be programmed into flash. Inside this function, CyBtldr_TransferData is responsible for transferring a buffer of data to the target device and later reading a response packet back from the device. CyBtldr_TransferData returns CYRET_ERR_COMM in case of any communication error talking to the device.
if (CYRET_SUCCESS != status)
err = status | CYRET_ERR_BTLDR_MASK;
Later, CyBtldr_ProgramRow is expected to return this error. Please let us know if you observe the same.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Genoa, we will put a trap in the host to check as suggested.
Kind regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Genoa
The trap has captured the break in the communications on the Host side, thank you! Capture from the host side debug shown below.
Moving across to the target, would the PSoC be recoverable if a packet was dropped? This is more an academic question for our manuals and existing field units.
Command Received: J
Program PSOC programming file...
PSOC file size = 71403 bytes
Parse programming file header
Start PSOC boot load operation
Process PSOC rows data...
Row data (array id=2, row num=79, row size=288)
Row data (array id=2, row num=80, row size=288)
Row data (array id=2, row num=81, row size=288)
Row data (array id=2, row num=82, row size=288)
Row data (array id=2, row num=83, row size=288)
ERROR: ReadIOMtrData() timeout
Verify row data error (15)
End PSOC boot load operation
Command Received:
Command Received:
Command Received: J
Program PSOC programming file...
PSOC file size = 71403 bytes
Parse programming file header
Start PSOC boot load operation
Process PSOC rows data...
End PSOC boot load operation
Regards
Greg
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since bootloading overwrites the application flash area, it's functionality will be lost. Bootloader needs to complete the bootloading to make that application (maybe application no:1 or application no: 2) active and valid again.
However, to guarantee that there is always a valid application, you can make use of Dual Application bootloader architecture supported by PSoC Creator bootloader component. This architecture supports two application images. You can either bootload both applications one after the other or configure one of them as the golden image (this image cannot be updated). Hence, even if one of the application is corrupted (due to any reason), the user can fall back to the other image. Later, when the communication channel becomes active, the corrupted application can be updated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Genoa
Thank you for your information, our systems already use dual applications with a bootloader.
We acknowledge that the PSoC is not immediately recoverable through a packet timeout or terminating command from the host; a power cycle of the target would be required.
Many thanks for your help with this item!