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.

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;
define symbol __ICFEDIT_region_ROM_BL_end__     = (0x0FE10000+0x4000-1);
define symbol __ICFEDIT_region_ROM_start__   = 0x0000;
define symbol __ICFEDIT_region_ROM_end__     = (0x00080000-1);
define symbol __ICFEDIT_region_RAM_start__   = 0x20000000;
define symbol __ICFEDIT_region_RAM_end__     = (0x20000000+0x00010000-1);

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.

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

Hello Ivan,

From a register perspective it seems that the configuration is correct following Table 19.10 in the xG13 reference manual:

• TX delayed start of transmission and CS setup
• TX Chip Select End Delay

Could you:

• Use different  cycles for CS HOLD so that we see the difference in delays
• Send a single character and verify if CS Hold is still missing
• Use one of the preconfigured delays instead of TIMECMP2 to verify that CS Hold operates

Are you using one of our examples to implement the basic USART communication?

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 */
  USART1->TIMECMP0 =  USART_TIMECMP0_TSTART_DISABLE | USART_TIMECMP0_TSTOP_TCMP0 | SPI_TX_DELAY_CYCLES;
  USART1->TIMECMP1 =  USART_TIMECMP1_TSTART_DISABLE | USART_TIMECMP1_TSTOP_TCMP1 | SPI_CS_SETUP_CYCLES;

  /* Configure CS HOLD time*/
  USART1->TIMECMP2 =   USART_TIMECMP2_TSTART_DISABLE | USART_TIMECMP2_TSTOP_TCMP2 | SPI_CS_HOLD_DELAY_CYCLES;

  /* Configure timing */
 USART1->TIMING = USART_TIMING_TXDELAY_TCMP0 | USART_TIMING_CSSETUP_TCMP1 | USART_TIMING_CSHOLD_TCMP2;
 

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_TX_DELAY_CYCLES       (25)   

  #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?

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);
                _serialPort.Handshake = Handshake.None;
               _serialPort.RtsEnable = true;   // necessary when using the BlueGiga devkit
               _serialPort.Open();

I hope it will help.

Ivan Dousa

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);
               _serialPort.Handshake = Handshake.RequestToSend;
               _serialPort.RtsEnable = true;   // necessary when using the BlueGiga devkit
               _serialPort.Open();

I hope it will help.

Ivan Dousa

Thank you Kevin.

Now it seems it is clear.