Hi,
I would like to burn a secondary bootloader into OTP via J-Link. I want to copy the application code to RAM from my host controller over UART. I want to configure GPIO pins P1_0 as Tx and P1_1 as Rx for bootloader. From where i can download the secondary bootloader program and how can i configure the Tx and Rx pins ?
Keywords:
Device:
Hi Vivek,
The secondary bootloader is located in the SDK in the utilities folder, you will have to define the SUPPORT_AN_B_001 in order to enable the secondary bootloader feature and then disable the spi and i2c interfaces via undefining the SPI_FLASH_SUPPORTED and the EEPROM_FLASH_SUPPORTED and define the UART_SUPPORTED. After doing that you will have to change the UART pins to the ones that you would like by changing the definitions of UART_GPIO_PORT, UART_TX_PIN and UART_RX_PIN. Doing the above should be ok, you can test the fw before burning it to the OTP by running it directly to sysram and download a fw to UART.
Thanks MT_dialog
Hi MT_dialog,
Thank you for quick reply. I have followed the steps you have explained in last reply. For testing I have downloaded the secondary bootloader firmware to sysram using Jlink and i have connected the Uart lines to PC through USB to uart converter. But I am not able see anything in uart lines. Once the bootloader firmware is successfully loaded, I am expecting that the BLE module will transmit "0x02" continuously.
I have downloaded SDK from "https://support.dialog-semiconductor.com/connectivity/product/da14580?qt..." and made the following changes in
bootloader.h and changed UART_GPIO_PORT , UART_TX_PIN and UART_RX_PIN macros.Please verify it.
changed line number 24 from #undef UART_SUPPORTED to #define UART_SUPPORTED
line number 27 from #define SPI_FLASH_SUPPORTED to #undef SPI_FLASH_SUPPORTED
line number 37 from #undef SUPPORT_AN_B_001 to #define SUPPORT_AN_B_001
Hi Vivek,
The configurations that i ve mentioned are valid, if you dont see the 0x02 that means that the device doesn't track the RX pin that you have set in hign state, in the bootloader in the main function in the UART supported section there is a condition if (GPIO_GetPinStatus(UART_GPIO_PORT, UART_RX_PIN)) that checks the RX pin before executing the scanning procedure.
Thanks MT_dialog
Hi MT_dialog,
I have checked voltage at Rx pin, I am getting 3.3 volts. But still i am unable to see 0x02.
If i am running the code in debug mode, It is working fine. I am able to see 0x02 in terminal and i am able to program other sample projects using SmartSnippets tool. I have followed the steps explained in Alps development kit application note for running in debug mode.
How can i make it working in release mode ?
Hi Vivek,
What exactly do you mean run the code in debug mode and release mode ? The secondary bootloader has the CFG_DEVELOPMENT_DEBUG definition disabled, running the project in RAM on my side allways outputs a 0x02 byte for booting from an external UART. I am not familiar with the ALPS document.
Thanks MT_dialog
Your side are you trying bootloader through P1_0 as Tx and P1_1 as Rx ?
Release mode means I will download the .hex file to sysRam using smartsnippet tool. In this method i am not getting 0x02.
For running in debug mode we have an option in kiel by clicking on the icon shown in attachment. Then we can do step by step execution or continuously run code. In this method i am getting 0X02. But for final product I want to use the hex file. So I want to verify it by downloading to sysRam before burning into OTP.
If you need alps document please send your email id tovivek@technosphere.inorjasim@technosphere.in
Hi Vivek,
I 've tested the downloading procedure via the Smart Snippets using the JTAG interface, indeed i see no action on P10 and P11 pins (i suppose that this is what you see) when downloaded the fw, but i also tried using the UART interface and probed the two pins and the fw was operating properly, i can assume that this is related with the downloading procedure and not with the .hex file produced, in both cases the .hex file is the same and its mirrored in sysram but for some reason when downloading the binary from JTAG using Smart Snippets the fw doesn't run, but again i dont think that this has nothing to do with the fw, if for example you load the binary to the flash in order to emulate an OTP copy it should work properly as well as downloading the fw via UART.
Thanks MT_dialog
Hi MT_dialog,
I have no option in my harware to tap PORT0 pins( which is using for inbuilt uart bootloader). So I have to use Jlink for loading secondary bootloader firmware. If i flash the secondary bootloader hex file to OPT using JLink, will it work properly? Or it will face same issue ?
Hi MT_dialog,
I have tried to burn hex file into OTP using Jlink. I followed WI_Dialog's instruction in the posthttps://support.dialog-semiconductor.com/program-da14580-otp-memoryand user manual "UM-B-083". But i am getting an error message "Adddittional error info at JTAG address 0x81FEC (MSB first): FF FF FF FE" and spoiled the OTP by writing 2 bytes before failing.
Please find the attached images.
Hi Vivek,
As mentioned in my previous post i suspect that the reason for not being able to download and run the secondary_bootloader directly from sysram using the Smart Snippets is the Smart Snippets it self, since i was able to download the .bin using SEGGER commander and downloaded and run the binary. So, no i dont think that will have this problem if you burn the secondary booter in OTP, i also tested this using the flash (bunred the secondary bootloader in the flash) and the binary run as it should.
Regarding the issue with the OTP. this is most probably an issue caused due to the OTP programming supply. So please check that.
Thanks MT_dialog
Hi MT_dialog,
Thank you for the suggestion. I have successfully burned the program into OTP(issue was with OTP supply 6.8). The secondary bootloader is working fine now. I am able to see 0x02 and i am able to load application to sysRAM using smart snippet tool.
But whenever i am loading application firmware though my host controller, it is not working. I am getting proper ACK while sending header(SOH and length) and i am getting CRC at end of firmware packet. since CRC is matching i am sending ACK to BLE module. But after that i am continuously getting "0x02".
It seems like BLE module is getting restarted and the data from OTP overwrites my application code.
Do i have to set something in OTP header to avoid this ? or is there anything missed in secondary bootloader firmware?
Note:-
I have made the following changes in OTP header as per Alps reference manual.
Application flag1: Yes・ Application flag2: Yes・ Calibration Flag: bit[4]=1. Xtal 16MHz Trim Values : 320・ DMA Length : 1FC0
Hi Vivek,
The sequence goes like so, the device will boot from OTP and it will load the custom bootloader from the OTP, the device will run the bootloader and start checking your custom ports as soon as the device finds something it will start copying the fw from the UART to the Sysram and then when the device succesfully finishes the download sequence it will branch to the newly downloaded fw. The fw of the secondary bootloader runs into the ret ram and not in the sysram, so i dont think that the OTP rewrites the fw downloaded into the sysram. Perhaps the downloaded fw runs and at somepoint it causes a reset to the device ? There is no additional configuration to burn in the OTP.
Thanks MT_dialog
Hi MT_Dialog,
"when the device succesfully finishes the download sequence it will branch to the newly downloaded fw."
>> I think this branching is not happening properly. I am sending ACK(0X06) after getting CRC from ble module. I hope the bootloader code have to take care of branching to newly downloaded firmware once it got ACK from host controller.
"Perhaps the downloaded fw runs and at somepoint it causes a reset to the device ?"
> >没有。我一直和我的应用程序代码和一个n example code in SDK (SDK 5.0.4\DA1458x_SDK\5.0.4\projects\host_apps\da1458x\proximity\reporter). I have sent the firmware contains in "prox_reporter_ext.h" file in the above mentioned project. In both case It failed. It is either getting reset or program is jumping to some wrong address and once the program counter reaches its maximum, execution is starting from reset address.
"There is no additional configuration to burn in the OTP."
>>Can you please verify my changes in OTP header? ( Application flag1: Yes・ Application flag2: Yes・ Calibration Flag: bit[4]=1. Xtal 16MHz Trim Values : 320・ DMA Length : 1FC0)
Hi Vivek,
Have you tested this in order to check if this is something that occurs under all circustances and not only when the bootloader is burned to the OTP ? For example have you tried to download the fw via keil (in order for the secondary bootloader to run), and while the secondary booter runs download the fw using the Smart Snippets booter tool ? I 've tried the above and i was able to boot from pins P10 and P11 via UART and check exactly where the secondary booter branches when succesfully uploaded an image.
I dont see anything wrong with the values that you have burned into the OTP, both flags should be set to yes in order to boot from OTP, regarding the XTAL 16MHz trim values that depends on your crystal, and the DMA length its not a necessity, but i dont think that it will cause you any issues.
对于分支,二级引导装载程序when the device has successfully downloaded the fw then it will go to the Start_run_user_application() in the sw_reset() the booter will assign the stack value from the vector table of the newly downloaded fw to the SP register and will then branch to the Reset_Handler of the downloaded fw.
Thanks MT_dialog
Hi MT_dialog,
谢谢你的支持。现在工作正常. Issue was with the way of reading firmware array. I have taken example code spi_booter.c from"SDK 5.0.4\DA1458x_SDK\5.0.4\projects\host_apps\da1458x\proximity\reporter\src" and converted it for uart interface. while converting , i have made a mistake which leads to read wrong address.