I've noticed a strange issue when use spi to connect serial nor flash to tlsr8258 in master mode.
I use 48 000 000 value macro in app_config and external 24 MHz crystal to derive the fastest system speed operation (originally project is a modified ble_sample example). A bulk write/read operation take giant time using API in spi.c source file. I measured with oscilliscope a spi SCLK pin signal and there i see 100-120 uS delays in between each byte transfer. This is during a phase where CMD byte is transmitted and system entered a for loop with bytewise write/read data bytes to HW spi data registers and polling bisy flag to mive to next byte in data array (this is what it looks like in spi.c api file). I've tryed to increase speed of initial speed of spi, and there i see that it really affects SCLK burst pulse's frequency, but a lag of ~100uS between each byte still remains.
Do i do anything wrong, or is that normal for tlsr8258 chip?
With that speed i can only achieve somewhat around 1 sec for 4kB sector block operaion with serial flash (it depends on if we process data in ram, or if both read and write are used).
Something similar i see with I2C, but there it is not that crytical in our app. There is also a related question about WaitUs API. When i try to call small 1－3 usec delay minimal i got is 2－3 time bigger, and its duration floats with 2－3 usec deviation when i put it in a loop for easier monitoring.
I suppose all above is related with slow system＿clock freq, which affects any processing capability and hw register read／write access. I‘ve already reported about giant lag in simple gpio toggle application in a infinite loop（about similar unstable 50－100 usec delays between gpio state changes even on a DevKit HW). Still has no idea is that all normal for a 48 MHz operated tlsr8258 or i misunderstand anything. Maybe proper ram＿code attribute should by selectively applied？Please, help.
|No related topics|