Member | Action | Date |
---|---|---|
|
Replied
to
OTA-Update failure 0x486
Please could you provide more details about that error code 0x486 ? What does it exactly mean? It seems it is not possible to find any details about this error code in the available documentation. |
34 days ago |
|
Replied
to
Linker file for bgm13s32f512
Thank you for the information. In my opinion it is quite confusing that the same information is not available in the datasheet. In addition the memory map drawing you can see in my question above that is present in the datasheet and also in the reference manual miss this bootloader sector.
Show more
|
53 days ago |
|
Selected an answer for
Linker file for bgm13s32f512
BGM13 is based on EFR32BG13, you could have a look at the EFR32xG13 reference manual, bootloader region start from 0x0fe10000.
Show more
|
53 days ago |
|
Posted
Linker file for bgm13s32f512 on
Bluetooth Forum
When I've created a SOC empty example project using the BLE SDK version 2.13.7.0 I've noticed that there is a default linker file "bgm13s32f512ga.icf" for IAR included. In this linker file I see following memory region definition: define symbol __ICFEDIT_region_ROM_BL_start__ = 0x0FE10000; When I compare this linker file content with the memory map available in the device datasheet it seems that there is no FLASH memory located in the area between address 0x0FE10000 and (0x0FE10000+0x4000-1) where the ROM_BL region is defined in the linker file. See the memory map print screen from the datasheet below: So it seems that the BL_ROM region is not correctly defined in the default linker file as it should be located probably at the FLASH start from address 0x0000 to 0x4000. Please could you confirm that I understood it correctly? Or is there any reason for such BL_ROM region definition? Thanks for your feedback.
|
55 days ago |
|
Replied
to
USART - CS SETUP and CS HOLD time configuration
Hello Antonio, Thank you for your reply, provided advices and double checking my configuration. I compared my code with an available code example for UART communication and I discovered that the issue was in the way I was handling the data transfer. As I set at the end of each data transfer USART_CMD_TXDIS bit and USART_CMD_RXDIS pin in the USART command register the CS was deaserted immediately and the expected CS HOLD time was not present. The inter-character delay was probably caused by polling USART_STATUS_TXC and USART_STATUS_RXDATAV bits in USART status resister and waiting till both are set before writing new data to TX Buffer Data Register. So i need to modify my code for SPI data transfer to avoid these problems. Thank you for your help. Best regards, Ivan |
Nov 23 2020, 9:16 AM |
|
Selected an answer for
USART - CS SETUP and CS HOLD time configuration
Hello Ivan, From a register perspective it seems that the configuration is correct following Table 19.10 in the xG13 reference manual:
Could you:
Are you using one of our examples to implement the basic USART communication? |
Nov 23 2020, 9:03 AM |
|
Posted
USART - CS SETUP and CS HOLD time configuration on
32-bit MCU - Microcontroller Forum
I would like to configure in my application a CS SETUP, CS HOLD and TX_DELAY time based on the picture below using the timer that is part of USART on BGM13S32 device. I followed the available documentation to configure the device accordingly: /* Configure delayed start of transmission and CS setup time */ /* Configure CS HOLD time*/
Where these constants SPI_CS_DELAY_CYCLES, SPI_CS_SETUP_CYCLES and SPI_CS_HOLD_TIME_CYCLES are defined as follows: /* Configure automatic CS pin control timing */ #define SPI_CS_SETUP_CYCLES (25) #define SPI_CS_HOLD_DELAY_CYCLES (25) Unfortunately, it seems that the CS HOLD time configuration does not work and ICS is configured instead of it. So as a result there is inserted inter-character delay of the configured time instead of delaying the CS signal releasing the configured time period as you can see on picture below: For that reason please could you confirm that the USART enable to use the CS setup, CS hold and TX delay time at the same time? If so, would it be possible to check if the configuration I use is valid or if there is some issue I need to fix to make it functional?
|
Nov 18 2020, 11:14 AM |
|
Updated
to
Wireless Board, switch/activate VCOM with C#
Hi Tom12345, I faced the exactly same issue with my application. At the end I discovered that the issue is caused by wrong configuration of used serial port in the application. Please note that it is necessary to set property "RtsEnable" before opening the serial port. Here is the related source of code for correct serial port configuration: _serialPort = new SerialPort(portName, 115200, Parity.None, 8, StopBits.One); I hope it will help. Ivan Dousa |
Oct 07 2020, 10:08 AM |
|
Replied
to
Wireless Board, switch/activate VCOM with C#
Hi Tom12345, I faced the exactly same issue with my application. At the end I discovered that the issue is caused by wrong configuration of used serial port in the application. Please note that it is necessary to enable handshake and set property "RtsEnable" before opening the serial port. Here is the related source of code for correct serial port configuration: _serialPort = new SerialPort(portName, 115200, Parity.None, 8, StopBits.One); I hope it will help. Ivan Dousa |
Oct 07 2020, 9:45 AM |
|
Replied
to
EFR32BG22 Bootloader in Gecko SDK Suite v2.7.6
Thank you Kevin. Now it seems it is clear. |
Sep 09 2020, 11:48 AM |