Hi,
On my own hardware I'm using UART2 for the serial bootloader and for the CLI. My serial interface are defined with TX and RX only, without a CTS line. To make it working for the CLI, I configured the CTS signal to an unconnected i/o pin with HW_GPIO_MODE_INPUT_PULLDOWN. My application is based on cscp_collector and hrp_collector . I'm using BTLE SDK 1.0.10-1072.
Everything is working well if BLE connects after a reset. But after a BLE disconnect or if BLE stays idle after a reset, the TX line goes down after a while. Then I cannot communicate anymore with UART2.
Switching sleep mode from pm_mode_extended_sleep to pm_mode_idle or pm_mode_active has no effect.
On an evaluation board everything is working well if I configure CLI to UART1.
I suppose that the issue is caused by the bootloader.
How can I fix this issue?
Many thanks for your help in advance.
Hi uniben,
I dont quite get what you are trying to do, the cli (i suppose that you mean the cli_programmer) is just for programming the 68x after you have burned the flash with a fw upon reset the device reloads the fw that is in the flash. Can you please let us know what exactly you are trying to do since the cli and the BLE projects are quite irrelevant.
The device boots only via UART1 and not via UART2. UART1 is the port that the 681 uses in order boot, that is defined via the ROM booter and its is fixed. So you will have to boot from the UART1 and download the uartboot.bin file (which acts as a secondary bootloader). The uartboot.bin file receives commands from the cli_programmer over UART2 (since now the device is running the uartboot.bin and not the ROM booter, so the uartboot.bin uses the same pins for a different UART), so the uartboot.bin, reconfigures the ports that the device is listening from UART to UART2. After you have downloaded a fw in the flash upon reset the device will load the fw that is located in the flash (and in all subsequent resets). If you have just booted the device with a custom fw, for example, just uplaoded a fw in the sysram, after a reset the device will just execute the ROM booter and the device will look communication over UART1 and not UART2, you will have to download the uartboot.bin again in order to switch ports.
Thanks MT_dialog
Hi,
Sorry for the unclear description. I'm using the cli and console from the sdk and they are sharing the same uart as the bootloader. My system is designed to use only one uart for flashing and wired communication.
Many thanks for your help.
Hi uniben,
仍然无法得到你想的东西to do. You are using somekind of UART interaction in your BLE project and at somepoint after the device disconnects the UART hangs. I am not sure i am getting this. Please try to be more specific on what is that you would like to do. When you mention cli i understand the CLI programmer that has nothing to do with a BLE project and its only used in order to program the device. You mention also that you are using the console, what console is that ? The console used in the peripherals demo ?
Thanks MT_dialog
Hi,
With cli I mean the command line interface which comes with the sdk. The cli is activated with:
#define dg_configUSE_CLI 1
#define dg_configUSE_CONSOLE 1
I started my project with the cscp_collector example project, which is controlled by the command line interface (cli).
My problem is, that both the bootloader (cerviced by the cli programmer) and the command line interface (which controls my application, similar to the example from cscp_collector) are using the same uart. Any procedure, somewhere in the depth of the sdk, is killing the uart, so that I have no access to my command line interface any more.
Many thanks for your help.
Hi uniben
I dont think that what you are experiencing is a bootloader issue, the bootloader is downloaded into the 68x and after the fw is downloaded into the device and the cli_programmer gets the command to burn the fw into the flash, after the reset, the bootloader in the sysram is wiped out by the application that you have just burned into the flash. In sub-sequent resets the primary bootloader will boot from flash. There is no collision between the bootloader and the application that runs in the device, if that was the case then the cspc_collector or the hrp_collector would not operate and they both use UART2.
Thanks MT_dialog
Thanks.