⚠️ Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.xmece.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
从#undef uart_supported到#define uart_supported更改了行号24 line number 27 from #define SPI_FLASH_SUPPORTED to #undef SPI_FLASH_SUPPORTED 从#undef support_an_b_001到#define support_an_b_001的行
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.
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.
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.
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 ?
我尝试使用jlink将十六进制文件刻录到OTP中。我跟随Wi_dialog在帖子中的指示https://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.
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.
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".
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.
“当设备成功完成下载序列时,它将分支到新下载的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 ?" >>不,我尝试过我的应用程序代码和SDK中的示例代码(SDK 5.0.4 \ da1458x_sdk \ 5.0.4 \ projects \ host_apps \ da1458x \ proximity \ eporter)。我已发送固件包含在上面提到的项目中的“prox_reporter_ext.h”文件中。在这两种情况下都失败了。它要么是重置或程序跳到一些错误的地址,一旦程序计数器达到其最大值,就会从重置地址开始。
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.
谢谢你的支持。现在工作正常. 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.
嗨Vivek,
辅助引导加载程序位于Utilities文件夹中的SDK中,您必须定义Support_An_B_001以启用辅助引导程序功能,然后通过拒绝SPI_FLASH_SUPOSTED和EEPROM_FLASH_SUPOSTED和定义UART_SUPPORTED并定义SPI和I2C接口并定义UEART_SUPPORTED禁用SPI和I2C接口。完成后,您必须通过更改UART_GPIO_PORT,UART_TX_PIN和UART_RX_PIN的定义来将UART引脚更改为您想要的。做上面的事情应该可以,你可以通过直接向Sysram运行并下载FW来测试FW之前将其测试到OTP之前。
谢谢mt_dialog.
嗨mt_dialog,
谢谢你的快速回复。我遵循了你最后回复的步骤。对于测试,我已使用JLink将辅助引导加载程序固件下载到Sysram,我已将UART行连接到PC到UART转换器。但我无法在UART行中看到任何东西。一旦成功加载引导加载程序固件,我期望BLE模块连续传输“0x02”。
我下载了SDK“https://support.dialog-semicondiondiondum/connectivity/product/da14580?qt ...“并进行了以下变化
bootloader.h并更改了UART_GPIO_PORT,UART_TX_PIN和UART_RX_PIN MACROS.PLEASE验证它。
从#undef uart_supported到#define uart_supported更改了行号24
line number 27 from #define SPI_FLASH_SUPPORTED to #undef SPI_FLASH_SUPPORTED
从#undef support_an_b_001到#define support_an_b_001的行
嗨Vivek,
如果您没有看到0x02,则提到的配置是有效的,这意味着设备不跟踪您在Hign状态中设置的RX引脚,在UART支持的部分中的主函数中的引导加载程序中有一个如果(GPIO_GETPINSTATUS(UART_GPIO_PORT,UART_GPIO_PORT,UART_RX_PIN))在执行扫描过程之前检查RX引脚。
谢谢mt_dialog.
嗨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 ?
嗨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.
谢谢mt_dialog.
你的身边是你通过p1_0作为tx和p1_1作为rx?
释放模式意味着我将使用SmartSnippet工具将.hex文件下载到Sysram。在这种方法中,我没有得到0x02。
在调试模式下运行,我们通过单击附件中显示的图标在基尔中有一个选项。然后我们可以通过步骤执行或不断运行代码来执行步骤。在这种方法中,我得到0x02。但对于我想要使用十六进制文件的最终产品。所以我想通过在刻录到OTP之前通过下载到Sysram来验证它。
如果您需要ALPS文件,请将您的电子邮件ID发送给vivek@technosphere.inorjasim@technosphere.in
嗨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.
谢谢mt_dialog.
嗨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 ?
嗨mt_dialog,
我尝试使用jlink将十六进制文件刻录到OTP中。我跟随Wi_dialog在帖子中的指示https://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.
请找到附加的图像。
嗨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.
谢谢mt_dialog.
嗨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".
似乎BLE模块正在重新启动,并且来自OTP的数据覆盖了我的应用程序代码。
我必须在OTP标题中设置一些东西来避免这种情况吗?或者在辅助引导加载程序固件中是否错过了任何东西?
笔记:-
根据ALP参考手册,我已经在OTP标题中进行了以下更改。
应用Flag1:是·应用程序标志2:是·校准标志:位[4] = 1。XTAL 16MHz修剪值:320·DMA长度:1FC0
嗨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.
谢谢mt_dialog.
嗨mt_dialog,
“当设备成功完成下载序列时,它将分支到新下载的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 ?"
>>不,我尝试过我的应用程序代码和SDK中的示例代码(SDK 5.0.4 \ da1458x_sdk \ 5.0.4 \ projects \ host_apps \ da1458x \ proximity \ eporter)。我已发送固件包含在上面提到的项目中的“prox_reporter_ext.h”文件中。在这两种情况下都失败了。它要么是重置或程序跳到一些错误的地址,一旦程序计数器达到其最大值,就会从重置地址开始。
“在OTP中没有额外的配置刻录。”
>>您能否验证OTP标题的更改吗?(应用程序标志1:是·应用程序标志2:是·校准标志:位[4] = 1. XTAL 16MHz修剪值:320·DMA长度:1FC0)
嗨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.
谢谢mt_dialog.
嗨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.