cancel
Showing results for 
Search instead for 
Did you mean: 

STEVAL-STLKT01V1: Firmware update.

CBram.1776
Associate II

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.

10 REPLIES 10
Eleon BORLINI
ST Employee

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
Associate II

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.

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

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.

Hi @CBram.1776​ ,

If you have an STLINK you can connect it to the Sensortile cradle and flash the ALLMEMS1 bin file (the one with the Bootloader) into the Sensortile L4 core.

0693W000005Bfj5QAC.png or

0693W000005BfkvQAC.pngWhen running the firmware on the STM32CubeProgrammer, you should first run the Full chip erase command so that the currently onboard firmware will be erased. Is the programmer able to detect your board (ST LINK configuration)?

0693W000005BfuHQAS.png 

-Eleon

Hello,

I flashed the STM32 with the ALLMEMS1_ST_BL.bin file that you have posted into your last message.

It happens that the SensorTile flashes its orange LED for some seconds, then it stops.

During this time, USB does not connect to the PC.

What is it expected to have done?

I also tried to flash my usual firmware, that works with a genuine SensorTile, but the BlueNRG-MS continues to not reply to the SPI commands that the STM32 BlueNRG-MS Library sends to it.

Have you some suggestions?

Because the problem is not the STM32 (that one works), but the external Bluetooth controller.

Sincerely.

EDIT: I tried to program another SensorTile with the STM32L476RG-SensorTile_ALLMEMS1_BL_v4.1.0.bin provided by ALLMEMS1 package, then I launched the ST BLE APP on Android and in this case the device has been found. From the menu, it is also possible to select the "Firmware update" option.

However, this seems to be possible only if the BlueNRG-MS has a working firmware inside. If not, like in my case, perhaps the only solution is to download a new firmware from the SPI interface. But, sadly, this does not seem to be working, at least with the functions and the information provided.

Hi @CBram.1776​ ,

After internal alignment with our experts, there's the possibility that you have bricked the BlueNRG.

To overcome this issue, you can try with flashing the attached binary file on the STM32: this .bin will allow you to use the BlueNRG-GUI and to flash the BlueNRG. Please assure that the IFR parameters are set as shown below:


_legacyfs_online_stmicro_images_0693W000005CWaAQAW.pngLet me know you are able to fix the issue with these indications.

-Eleon

Hello,

Thank you very much again for your support but unfortunately the SensorTile has not been resurrected.

1) I flashed the SensorTile with the file "SensorTile_BLE_Updater_VCP svn126.bin" that you have sent to me.

2) I launched BlueNRG GUI v4.0.0: in the combobox with the list of COM ports, I have found "COM22 (ST DK)", which is evidently the SensorTile connected to the PC.

3) I selected "Tools->IFR/Device Configuration...", then I have set the options as you suggested in your screenshot. Finally, I pressed "Append to FW..." button, I selected "Firmware->BlueNRG-MS_stack->bluenrg_7_3_Mode_2-32MHz-XO32K_4M.bin" and I saved it as "carlo.img", to be sure to not corrupt original file.

0693W000005CtyfQAC.png 

At this point, I pressed "Open" button on the main window and the software prints these errors:

0693W000005CtzwQAC.pngand then:

0693W000005Cu0BQAS.png 

If I select from the menu "Tools->Stack updater...", I select "BlueNRG-MS" from the combobox, then it opens this dialog box and I select the "carlo.img" file that I created with your guidelines. If I press the "Update" button, nothing happens except that it prints these yellow messages inside the parent window:

"Job start"

"Job finished"

0693W000005Cu0kQAC.pngand an exception error is showed when I close that dialog box:

SerialException WriteFile failed (Windows error(22, "Il dispositivo non riconosce il comando"))

0693W000005Cu14QAC.pngNote, that italian sentence means "The device does not recognize the command" in english.

However, the SensorTile is still not functional as it was before.

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)".

0693W000005Cu2MQAS.pngshowing that the firmware you sent me is actually working.

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

Thank you very much for your support and your time.

Sincerely.

Eleon BORLINI
ST Employee

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