Cypress API - Communication interruption of RS485 while programming PSOC5

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

cross mob
GrLe_1336286
Level 3
Level 3
25 replies posted 10 replies posted 5 replies posted

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

0 Likes
1 Solution

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.

View solution in original post

0 Likes
18 Replies
DheerajK_81
Moderator
Moderator
Moderator
First comment on KBA First comment on blog 5 questions asked

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

0 Likes

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

0 Likes

Hi Dheeraj

Any further thoughts or would this warrant creation of a support ticket?

Regards

Greg

0 Likes
GeonaP_26
Moderator
Moderator
Moderator
250 solutions authored 100 solutions authored 50 solutions authored

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.

0 Likes

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

0 Likes

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.

0 Likes

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

0 Likes

Hello Geona

Any further comments on this item?

Regards

Greg

0 Likes
Ekta_N
Moderator
Moderator
Moderator
750 replies posted First like given 250 solutions authored

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

0 Likes

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

0 Likes

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

0 Likes

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;

pastedImage_0.png

0 Likes

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.row_failure.png

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

0 Likes

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.

0 Likes

Thanks Genoa, we will put a trap in the host to check as suggested.

Kind regards

0 Likes

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

0 Likes

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.

0 Likes

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!

0 Likes