2020-11-10 04:12 AM
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:
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.
2020-11-13 07:07 AM
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
2020-11-16 05:24 AM
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.
2020-11-16 05:46 AM
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
2020-11-16 09:28 AM
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.
2020-11-17 06:04 AM
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.
or
When 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)?
-Eleon
2020-11-18 01:48 AM
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.
2020-11-24 09:53 AM - edited 2023-11-20 09:22 AM
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:
Let me know you are able to fix the issue with these indications.
-Eleon
2020-11-27 04:53 AM
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.
At this point, I pressed "Open" button on the main window and the software prints these errors:
and then:
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"
and an exception error is showed when I close that dialog box:
SerialException WriteFile failed (Windows error(22, "Il dispositivo non riconosce il comando"))
Note, 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)".
showing 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.
2020-11-30 03:10 AM
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