Hello,
I am developing a custom board with DA14531 and a NXP chip, attached via SPI. As development environment I use the Pro Deveopment board, with the DA14531 daughter.
I pulled the jumpers for SPI, in order to connect my target, residing within it's own board environment.
The NXP chip expects a simple protocol. On a read, the 7 upper bits are the register address and bit 0 decides about a read or write.
Consequently, I guess, have to transfer 2 bytes on a read, the second is ignored, but MISO is driven by the NXP chip.
I am now stuck within the library. I switched off the DMA configuration parameter in the project (removed the define CFG_SPI_DMA_SUPPORT) and prepared my 'read_register' function.
The library stops by an endless loop at line 903 of file spi931.c :
// Wait while RX FIFO is empty while (spi_rx_fifo_empty_status_getf() == SPI_RX_FIFO_IS_EMPTY);Here is my library call:
unsigned char getRegister(unsigned int reg_address) { unsigned char reg_addressv = reg_address; for(int i=0; iThe line of interest is, where spi_transfer() is called.
The SoC initialisation is taken from the spi_flash project, the interface is set to byte transfer.
In fact, I took that spi_flash example as code base and modified it. All initialisation is kept as is - except for removal of DMA support.
我不处理中断。
What might be wrong ?
Why is the rx fifo empty ?
It should be nonempty, even if there is nothing attached to the SPI port pins, am I wrong?
Thanks for help and hints,
Joachim
Hi joachimkr,
Could you please share how you are connected the external MCU with the DA14531 DK?
So, did you run it with the debugger attached and the firmware stuck at this line?
Would it be possible to use a logic analyzer, probe the SPI lines and share an SPI capture?
Thanks, PM_Dialog
Hello,
thanks for reaction. Your question assumed, it would be an NXP CPU, which is attached. No, it is a peripheral. To answer your questions:
The debugger stopped, looped in the given line. I will now attach an analyzer, in order to make sure, I get all reactions expected:
In the meantime, I was able to resolve the very basic issue. It turned out, the SPI controller was dependent on the call to setting the CS signal active, before calling the transaction function. After activating CS (in my case low), the spi controller worked, I passed the line, got one byte result, as expected. When attaching MISO to low, it was zero, when high, 0xFF, as expected.
That dependency is not described, neither in the code, nor in the datasheet.
I propose, to add comments in the source code of the example. Additionally, I disabled the DMA via project level define and noticed successful run thru the flash memory test code. Some descriptions of the library are missing. The more basic, it is more important ;-)
Nevertheless, it is clean and clear code!
Thanks for comment,
Greetings, Joachim
Another issue raised. The byte-'wide' peripheral device expected at least 2 bytes sequentially, the second to return the correct content of the addressed register.
In order to resolve that, I added a utility for register access, which sent a dummy byte (with it's clock pulses) after command, in order to get the return value.
The first byte in the RxFifo is ignored, rubbish. The second byte is returned as function result.
我很满意,但提出一些补充itional comments in the library code. I assume, I am not alone with similar hickups.
Overall: Great Work!
Joachim
Hi joachimkr,
Thank you. Your suggestion is very good
Br, Yibin