OTA application loses incoming packets

Vyacheslav · ‎2019-09-24

Hi.

Based on the OTA example, I created an application. The only difference is the use of MTU = 256.

The length of the characteristic is equal to MTU android pixel (126)

The problem is that when sending firmware from a custom application to an Android Pixel, all packages very rarely arrive. A lot is lost.

At the same time, when testing on Android Nexus 7, all packages come.

At first, I decided that a Pixel transmits data faster than a Nexus and reduced the transmission speed by delay. Only a delay of 100ms between the transfer of packets allowed to receive all packets.

But at the Nexus, packets are transmitted approximately every 20ms and everything comes.

Then I limited the length of the characteristic to 20 bytes and nothing changed, when transferring from a Pixel, data is lost.

The next step, on the chip side, I removed the code that writes to the flash and bingo!, with a characteristic length of 126, without using the delay, all the data comes.

Question to the respected community and STM engineers: why can this be? Will you throw any other ideas?

Regards,

Vyacheslav.

Remi QUINTIN · ‎2019-09-25

Flash access during RF activity is at risk as the BLE stack brings real time requirements. This is why, during Radio activity, any Flash erasure or store shall not be started. The constraint is not on saving data, the constraint is really on the erasing process of the flash memory that is a blocking process that can lead to the loss of the current BLE connection. So any write access to the flash memory must be done on a previously erased/empty flash memory sector.

Nota that this limitation is under evaluation and should be removed with the next FW versions. The BLE stack will suspend any new Flash sector erase and store operation (FLASH_C2SR.PESD). During Radio critical phase active, it would also manage the critical phase end interrupt (PWR_EXTSCR.CRPF, PWR_SR1.CRPEF).

In the end, removing the flash access in your code enables the complete and correct data transfer.

View solution in original post

Remi QUINTIN · ‎2019-09-25

Flash access during RF activity is at risk as the BLE stack brings real time requirements. This is why, during Radio activity, any Flash erasure or store shall not be started. The constraint is not on saving data, the constraint is really on the erasing process of the flash memory that is a blocking process that can lead to the loss of the current BLE connection. So any write access to the flash memory must be done on a previously erased/empty flash memory sector.

Nota that this limitation is under evaluation and should be removed with the next FW versions. The BLE stack will suspend any new Flash sector erase and store operation (FLASH_C2SR.PESD). During Radio critical phase active, it would also manage the critical phase end interrupt (PWR_EXTSCR.CRPF, PWR_SR1.CRPEF).

In the end, removing the flash access in your code enables the complete and correct data transfer.

Vyacheslav · ‎2019-09-26

Ok, thanks for response !