errors when programming CYBLE-012011-00 via SWD from external MCU with 001-84858_AN84858

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

cross mob
BIHO_4269506
Level 1
Level 1

Hello,

For the needs of a test jig we have to program the CYBLE-012011-00 with an external MCU, in this case an ESP32, for that purpose we used the app note 001-84858_AN84858 and ported the firmware to our host, after using C_Hssp_TimeoutCalc.cydsn and a scope to determine timeouts.

The 100uS delay function is implemented with an exact 1 uS timer and verified with scope as well.

I added some printf statements in order to see where the failure is occuring :

system init

0x0bb11477

Read_IO DRW_READ 2 ERROR 0x04

Read_IO TAR_WRITE ERROR 0x07

SROM_STATUS ERROR

SROM ERROR

ERROR

0

As we can see the chip ID is correctly read and valid, then there is an error in PollSromStatus(void) in programmingSteps.c coming from ReadIO() in SWD_UpperPacketLayer.c .

First error is on the second read, and then on the first write. The error code shown is swd_PacketAck value.

Tired to increase SROM_POLLING_TIMEOUT but of course it doesnt change anything, since the error is not related to the timeout. The error occurs here :

  /* Enter CPU into Test Mode */

  Write_IO (TEST_MODE, 0x80000000);

  if ( swd_PacketAck != SWD_OK_ACK )

  {

    printf("WRITE TEST_MODE ERROR\n");

    return (FAILURE_);

  }

  Read_IO (TEST_MODE, &status);

  if ( swd_PacketAck != SWD_OK_ACK )

  {

    printf("READ TEST_MODE ERROR\n");

    return (FAILURE_);

  }

  if ((status & 0x80000000) != 0x80000000)

  {

    printf("READ TEST_MODE ERROR 0x%02x\n",status);

    return (FAILURE_);

  }

  /* Read status of the operation */

  result = PollSromStatus();

  if (result != SROM_SUCCESS)

  {

    printf("SROM ERROR\n");

    return (FAILURE_);

  }

it cannot read back the test register.

and the error occurs here :

unsigned char Read_IO( unsigned long addr_32, unsigned long *data_32)

{

    Write_DAP(DPACC_AP_TAR_WRITE, addr_32);

    if (swd_PacketAck != SWD_OK_ACK)

    {

      printf("Read_IO TAR_WRITE ERROR 0x%02x\n",swd_PacketAck);

        return (swd_PacketAck);

    }

   

    Read_DAP(DPACC_AP_DRW_READ, data_32);

    if (swd_PacketAck != SWD_OK_ACK)

    {

      printf("Read_IO DRW_READ 1 ERROR 0x%02x\n",swd_PacketAck);

        return (swd_PacketAck);

    }

       

    Read_DAP(DPACC_AP_DRW_READ, data_32);

    if (swd_PacketAck != SWD_OK_ACK)

    {

      printf("Read_IO DRW_READ 2 ERROR 0x%02x\n",swd_PacketAck);

        return (swd_PacketAck);

    }

    return (swd_PacketAck);

}

To make sure it was not an issue with this MCU i implemented the firmware on an STM32 board (STM32L432KC) and i got exactly the same errors :

system init

0x0bb11477

Read_IO DRW_READ 2 ERROR 0x04

Read_IO TAR_WRITE ERROR 0x07

SROM_STATUS ERROR

SROM ERROR

ERROR

0

That lead me to think there is something wrong with this firmware and it just doesnt work.

It is a rather critical and urgent matter because we use this for a test jig for PCBA production that should be sent to the facility next week, so if someone from the support could look into the issue we would really appreciate.

Thank you.

0 Likes
1 Solution

I would like to know what is the maximum clock speed allowed.

As per datasheet, the maximum allowed clocking on SWDCLK is 14MHz for 3.3V~5.5V and 7MHz for 1.71V~3.3V ranges. In addition, it is recommended that SWDCLK <= 1/3 CPU clock frequency. But this is the physical limitation only.

Real SWD clock for stable device communication depends on many factors, including latency of read/write operations for each specific hardware block debugger is communicating with. A very important factor here is how the debugger implements programming and low-level communication algorithms.

For example, if the debugger requesting read or write operation when the previous one is not completed yet, the target will return WAIT response. This is normal and a situation that is allowed, BUT the debugger must implement correct WAIT responses handling. I don’t think the HSSP application code implements this handling. Hence, I would not increase the clock above, let's say 3MHz, because failures can occur in different places.

i would like to know what is the normal programming and verification time for the entire flash of this particular module (128K). And how much time i should wait for row writing and 4 byte reading operations before polling the status in SRAM

The flash AC Specifications are in Table 37 in the datasheet. But note that these are hardware block capabilities and does not include any overhead in real world. As for <how much time I should wait before polling something> - normally zero.

I do not recommend using the Application Note based HSSP Programmer for production programming if that is what you require this for.

Regards,
Dheeraj

View solution in original post

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

The swd_PacketAck variable is the status byte to infer error details from the bit field definitions. See figure below for the bit fields returned by this function:

hssp.PNG

The error values 0x04 and 0x07 you received indicates that the SWD transaction returned a FAULT response. This usually occurs when the timing requirements aren't met. The first step of the HSSP “Device Acquire” has strict timing requirements with regards to entering the programming mode. One of the important requirements is to ensure that the frequency of SWDCK clock line is at least 1.5 MHz to meet the acquire window timing. Ensure that there are no interrupt events in the host processor, which can affect the code execution time for completing the “Device Acquire” step on the host processor side.

Can you please attach the scope shots so that we can have a look at what might be going wrong?

Regards,

Dheeraj

0 Likes

Hello Dhjeeraj,

Thank you for the reply. Since then i have worked quite a lot on this, and i could pass the acquisition phase as well as few othre phases.

Today i even managed to pass the write and verify phase, however it took quite a lot of tweaking and there is still some issues.

First the clock speed, it has been verfied on the scope to be 3.5MHz, i can go up to 10MHz when using direct register access for GPIOs manipulation. I would like to know what is the maximum clock speed allowed.

Second point is the speed, most tweaking required to get this firmware to work are relative to non blocking write and read operations, involving to poll the status from SRAM. That is the write operations latch operations and read operations. It is apparently impossible to get them working with the timeouts defined with the 100uS delay (which has been verified to be exact on the scope) despite i strictly followed the app note procedure to determine appropriate timings, worst is even when increasing ridiculously these values (*5 or *10) there was still errors at such point that it couldnt read more than 3 or 4 row before failing.

To fix all that i had to introduce some millisecond blocking delays at various points in the functions, especially before PollSromStatus(), in LoadLatch() and after Read_IO( rowAddress + i, &flashData) in VerifyFlash(). Now i can write the entire flash and verify it, however the speed is obviously extremely slow, few hundred mS per row.

So i would like to know what is the normal programming and verification time for the entire flash of this particular module (128K). And how much time i should wait for row writing and 4 byte reading operations before polling the status in SRAM, in order to increase the overall speed, which is currently way too slow.

This informations together with the maximum SWD clock speed allowed should help me to definitely fix the firmware and go ahead.

Thank you.

0 Likes

I would like to know what is the maximum clock speed allowed.

As per datasheet, the maximum allowed clocking on SWDCLK is 14MHz for 3.3V~5.5V and 7MHz for 1.71V~3.3V ranges. In addition, it is recommended that SWDCLK <= 1/3 CPU clock frequency. But this is the physical limitation only.

Real SWD clock for stable device communication depends on many factors, including latency of read/write operations for each specific hardware block debugger is communicating with. A very important factor here is how the debugger implements programming and low-level communication algorithms.

For example, if the debugger requesting read or write operation when the previous one is not completed yet, the target will return WAIT response. This is normal and a situation that is allowed, BUT the debugger must implement correct WAIT responses handling. I don’t think the HSSP application code implements this handling. Hence, I would not increase the clock above, let's say 3MHz, because failures can occur in different places.

i would like to know what is the normal programming and verification time for the entire flash of this particular module (128K). And how much time i should wait for row writing and 4 byte reading operations before polling the status in SRAM

The flash AC Specifications are in Table 37 in the datasheet. But note that these are hardware block capabilities and does not include any overhead in real world. As for <how much time I should wait before polling something> - normally zero.

I do not recommend using the Application Note based HSSP Programmer for production programming if that is what you require this for.

Regards,
Dheeraj

0 Likes