STEVAL-STLKT01V1: Firmware update.

[CBram.1776]

Hello,

I'm using STEVAL-STLKT01V1.

Then, I downloaded ST BlueNRG GUI 4.0.0, which provides these firmwares into the Firmware\BlueNRG_stack directory:

• bluenrg_6_4b_Mode_2-16MHz-XO32K.img
• bluenrg_6_4b_Mode_2-16MHz-XO32K_HCI.img
• bluenrg_6_4b_Mode_2-32MHz-XO32K.img
• bluenrg_6_4b_Mode_2-32MHz-XO32K_HCI.img
• bluenrg_7_3_Mode_2-16MHzXO32K_4M.img
• bluenrg_7_3_Mode_2-32MHz-XO32K_4M.img

What is the best one to use?

If it is not one of these, or if a more updated version exists for it, where could I find the right one?

According to the documentation, the STEVAL-STLKT01V1 should be factory-flashed with bluenrg_7_1_e_Mode_2-32MHz-XO32K_4M.img, so in my opinion I should use bluenrg_7_3_Mode_2-32MHz-XO32K_4M.img but I prefer to ask to be sure before doing damages.

Thank you very much for your time.

Sincerely,

Carlo Bramini.

[Eleon BORLINI]

Hi Carlo @CBram.1776​ ,

According to the default fw (bluenrg_7_1), you correctly guess that the bluenrg_7_3 is the most suitable one.

If, for any reason, the firmware upload should go wrong, you could even program the STLKT01V1 through the SWD connector.

By the way, did you already try to upload the bluenrg_7_3 firmware? And, if so, was everything ok?

-Eleon

[CBram.1776]

Hello,

I tried to update the firmware, but it seems that something went wrong.

This is the code that I have implemented inside my program:

#include "bluenrg_7_3_Mode_2-32MHz-XO32K_4M.c"
 
static uint8_t ifr_data[192];
 
void BlueNRG_RST(void)
{
 HCI_TL_SPI_Reset();
}
 
void BlueNRG_HW_Bootloader(void)
{
 GPIO_InitTypeDef GPIO_InitStruct;
 
 HAL_NVIC_DisableIRQ(EXTI9_5_IRQn);
 
 // Pull IRQ high
 GPIO_InitStruct.Pin = HCI_TL_SPI_EXTI_PIN;
 GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 HAL_GPIO_Init(HCI_TL_SPI_EXTI_PORT, &GPIO_InitStruct);
 HAL_GPIO_WritePin(HCI_TL_SPI_EXTI_PORT, HCI_TL_SPI_EXTI_PIN, GPIO_PIN_SET);
 
 // Reset cycle
 BlueNRG_RST();
 
 // IRQ input
 GPIO_InitStruct.Pin = HCI_TL_SPI_EXTI_PIN;
 GPIO_InitStruct.Mode = GPIO_MODE_IT_RISING;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 HAL_GPIO_Init(HCI_TL_SPI_EXTI_PORT, &GPIO_InitStruct);
 
 HAL_Delay(5);
 
 HAL_NVIC_EnableIRQ(EXTI9_5_IRQn);
}
 
void HCI_Process(void)
{
 if(HCI_ProcessEvent)
 {
 HCI_ProcessEvent=0;
 hci_user_evt_proc();
 }
 User_Process();
}
 
void SysUpdateBlueNRG(void)
{
 uint8_t hwVersion;
 uint16_t fwVersion;
 int res;
 
 if (getBlueNRGVersion (&hwVersion, &fwVersion) != BLE_STATUS_SUCCESS)
 return;
 
 if (fwVersion < 0x730) {
 if (read_IFR(ifr_data) != 0)
 return;
 
 res = program_device(fw_image, sizeof(fw_image));
 
 if (res == BLE_STATUS_SUCCESS)
 program_IFR(ifr_data);
 }
 }
 

and the main program calls function SysUpdateBlueNRG() after the stack has been initialized.

Unfortunately, after updating the firmware a first time, apparently successfully, the BlueNRG controller does not seem to work anymore and it does not reply to the commands.

Is there a way to recover the device?

Sincerely.

[Eleon BORLINI]

Hi @CBram.1776​ ,

did you also try to upload the file with the ST BLE app, as described in the User Manual p.47?

(Note: The binary file must only contain the application firmware; it is not possible to upgrade the boot loader as well).

>> after updating the firmware a first time, apparently successfully

Do you mean that you upgraded the firmware for the first time, and then you failed upgrading the same firmware for the second time?

By the way, you did the right thing, since the SensorTile mounts BlueNRG-MS and on the BlueNRG GUI user manual you can find the following statement:

Go to settings → Fw Stack Version-> select FW 7.x or 7.1 for the BlueNRG-MS device, FW 6.4 for the BlueNRG device, FW 1.0 or FW 2.x for the BlueNRG-1 device and 2.x for the BlueNRG-2 and FW 3.x for the BlueNRG-LP device.

Please note however that the standard way to debug and develop codes with the STEVAL-STLKT01V1, and in general with all the STM32 board, is using an STLINK V2 or V3, as described in this presentation. You can use the free STM32CubeProgrammer IDE for this scope (here a tutorial).

You can flash on your board a one of the FP-SNS-ALLMEMS1 function pack application, for example the one in the folder \Projects\Multi\Applications\ALLMEMS1.

-Eleon

[CBram.1776]

Hello,

thank you very much for your quick reply.

This is what I did:

1) I had a working SensorTile.

2) Since I wanted to update the firmware of the BlueNRG-MS to the latest available version, I included in my program the piece of code that I posted previously.

3) I flashed my program with JTAG-SWD into the STM32L476 included into the SensorTile and I stated the execution.

4) After my program went out from my function SysUpdateBlueNRG(), the BlueNRG-MS does not give signs of life.

The radio does not seem to be functional anymore and using an application ST BLE APP is *NOT* possible.

It seems that for some unknown reasons (to me), the firmware upgrade bricked the BlueNRG-MS.

Every executed command sent on the SPI interface returns timeout.

However, I read on the AN4491 BlueNRG, BlueNRG-MS updater guide, page 3:

The updater is an independent program that resides within the BlueNRG device. It allows

changing of the BlueNRG firmware, by receiving a new version via serial port (SPI), and

reprogramming the Flash memory. The updater cannot change itself.

and later:

Even if the BlueNRG firmware is corrupted, or if the 62 KB firmware region and/or

2 KB IFR Flash are empty, the updater is still able to turn on the system, wait to receive new

firmware, and then update the Flash. So it can safeguard the system and bring it back to a

known working state.

So, perhaps, if something failed into the process, the BlueNRG-MS entered in this state.

However, I also read on page 6:

If the IRQ pin is detected high during BlueNRG startup (power-up or hardware reset), BlueNRG enters updater mode.

and unless I have misunderstood something, this is what I was already doing already in my code.

I also read that this bootloader recognizes just a limited number of functions:

aci_updater_start

aci_updater_reboot

aci_get_updater_version

aci_get_updater_buffer_size

aci_erase_blue_flag

aci_reset_blue_flag

aci_updater_erase_sector

aci_updater_program_data_block

aci_updater_read_data_block

aci_updater_calc_crc

aci_updater_hw_version

But, for example, I tried to execute these commands also on another *WORKING* SensorTile and calling aci_get_updater_version() always returns BLE_STATUS_TIMEOUT. Other commands works fine, I can do connections and data transfers, but these commands don't run. This happens in both normal mode and updater mode.

And trying to update again the SensorTile, it fails leaving to me an unusable device, because the above functions return a failure value.

It is quite strange, because it seems like the IRQ line doesn't move when the device is in updater mode.

I hope that there is a solution to this problem, because I have two bricked SensorTile devices that don't work anymore and I need to recover their functionalities.

Sincerely.

[Eleon BORLINI]

Hi @CBram.1776​ ,

Thank you for your detailed reporting of your procedure.

>> If I program the file "SensorTile_BLE_Updater_VCP svn126.bin" inside a new SensorTile, I'm getting this screen:

>> "Old firmware detected on the motherboard. Update motherboard firmware (under Tools menu)".

You had the possibility to test the procedure on another SensorTile, right? And is it working on it?

>> Is it possible that the BlueNRG-MS could be permanently damaged if something wrong (power loss, corrupted FW, etc) happened during the update process?

It's strange but yes, you could be right, especially in the case the FW is working on another SensorTile and not on your first one.

-Eleon

[CBram.1776]

Hello,

>> You had the possibility to test the procedure on another SensorTile, right? And is it working on it?

Yes, it does (see last screenshot). I have not tried to do the download because I'm a bit worried to brick another one, but actually the *working* SensorTile is providing a different message when the "CONNECT" is done.

>> It's strange but yes, you could be right, especially in the case the FW is working on another SensorTile and not on your first one.

This is not a reassuring thing.

Sincerely.