[color=red]Figure1[/color] is a complete signal sequence of SPI,which reading the device id register.This register is located at 0x00.
[color=red]Figure2[/color] is Bit of the first byte that DW1000 translate.
[color=red]Figure3[/color] is detail of the SCK raising.
The SPI of host microcontroller is configured as SPI_MODE_0,which CPOL = 0 & CPHA = 0.The frequency of SCK is about 90KHz.As the description of the SPI_MODE_0 in SPI specification.The SPI master sample the signal on MISO at the raising edge of SCK.And the slaver latch the next bit at the falling edge of SCK. According to the signal time sequence in Figure3,DW1000 latch the next bit after 20ns(nanoseconde) of SCK rising edge. It’s not consistent with the description in the datasheet of DW1000. We use a MCU(named Apollo_III of Ambiq semiconductor) to drive the DW1000.However the dw1000 can’t translate or receive packet normally.
[color=#ff3333]Question:[/color]Is there a problem with the time sequence of the SPI of Apollo III? This will cause an exception with the SPI operation of some MCUs.
from SPI point of view it is correct. Data can change in any time after sampling edge. DW1000 change MISO cca 13ns~20ns after sampling edge - so it is fully legal. However some MCU cant handle it even if datasheet says that it can handle. I had the same problem with ATMEL MCU - it didnt work with SPI and it did work with USART configured to SPI. Im expecting that you are reading data one bit shifted (missing first bit) - try to read device ID and shift the data by one bit.
Luckily there is failsafe bit in DW1001 register.
Write this on blind
sys_config = 0x1600;
I think that I should tell the detail of the problem when I use Apollo III to drive DW1000.
The driver consist of 2 parts,one of them is initializing the DW1000,and the other is send wireless packet. Initializing part may be ok,because MCU get correct device id from device_id_register.However each spi instruct can not be detected,it is too much.After initializing,sending packet in immediately mode is proceed.However we can't catch the packet by the UWB sniffer tool,but the interrupt of transmitting complete generated,and the interrupt_service_routine execute normally.I read back sending data from the tx_buffer(located at 0x09),it is equal to the content what I writing.
To locate the question, I implement the SPI by GPIO simulating.The packet can be catched by the UWB sniffer tool normally,when only SPI interface replaced.
Incorrect SPI commucation cause the exception,but not every SPI instruct has a problem.
Question:What's the cause of this problem?What can I do under the condition of " do not change the MCU"?
I have already test the SPI_MODE_3 with [color=#000000][size=medium][font=Microsoft YaHei]SYS_CFG.SPI_EDGE = 0,however it doesn’t work normally.I will test the SPI_MODE_3 with [color=#000000][size=medium][font=Microsoft YaHei]SYS_CFG.SPI_EDGE = 1 later.And tell you the result when done.[/font][/size][/color][/font][/size][/color]
Well,I config the SPI of the mcu in spi_mode_3,and read the device id register of the dw1000.The follow griph_1 is the time sequence of the SPI.The arrow on the clock is the sampling rising edge.The graph_2 is the first byte which dw1000 return,the 0x30 of 0xdeca0130.In the graph_2,an error time sequence present.
[color=#ff3333]Question[/color]:Does DW1000 support SPI_MODE_3 correctly(support described in datasheet)?Do you use the SPI_MODE_3 to drive the DW1000?
you cant change SPI mode “randomly”, you need to force DW1000 to use SPI 3 mode via its GPIO pins.
Have you tried my advice (write 0x[color=#333333][size=small]0x1600 to [color=#333333][size=small]SYS_CFG_ID)[/size][/color][/size][/color]?
You have mentioned some analyzer - which kind of analyzer?
I done a wrong test before.The spi_mode of DW1000 is config by the GPIO_5 & GPIO_6.The mode determined by the sampling of these pins when power up.I have alreay connect them to specified logic level to work at mode_0 & mode_1 & mode_2 & mode_3.However,the trouble alway exist no matter SYS_CFG_ID.SPI_EDGE = 0 or 1.And the problem behavior are same for each mode.
I think the trouble belong to the MCU,not dw1000.I have already contact the FAE of the MCU.
The analyzer is a simple logic analyzer,which designed by a company of China.It support 16 channel simultaneously with maximum bandwidth 16MHz,and 3 channel simultaneously with maximum bandwidth 100MHz.It supports common protocols,such as I2C SPI UART USB_FS and so on.The follow is the website of the company.