Dynamic reconfiguration of peripheral HW from TWI to SPI

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

Vincent Belaïche — Mon, 28 Oct 2024 12:48:46 GMT

I am a bit confused to inform you that this discussion was just making a lot of noise for nothing. A few weeks ago I realized that the root cause of the problem was that the peripheral setup time (from the reset signal raising to the first access on the bus) was too short.
For some reason this had gone unnoticed up to lately and I had sought the problem in the wrong direction and fixed it without understanding why the fix was making things work.
At least I hope the discussion can be useful to other people in the sense that one should double check one more time that startup timings specs and other basic settings are fulfilled before blaming the SDK.

Lots of thanks for your kind help anyway.

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

haakonsh — Fri, 21 Sep 2018 14:01:53 GMT

Thank you for sharing your findings, we'll try to reproduce it on our end and see what we find :)

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

Vincent Belaïche — Thu, 20 Sep 2018 09:10:05 GMT

For completeness, here is the patch that makes it work for me (I replaced the copy to array by some delay which I empirically found):

diff --git a/nrf-sdk/modules/nrfx/drivers/src/nrfx_twi.c b/nrf-sdk/modules/nrfx/drivers/src/nrfx_twi.c
index c7492bd4..c9080024 100644
--- a/nrf-sdk/modules/nrfx/drivers/src/nrfx_twi.c
+++ b/nrf-sdk/modules/nrfx/drivers/src/nrfx_twi.c
@@ -49,6 +49,8 @@
#include <nrfx_twi.h>
#include <hal/nrf_gpio.h>
#include "prs/nrfx_prs.h"
+#include "nrf_delay.h"
+

#define NRFX_LOG_MODULE TWI
#include <nrfx_log.h>
@@ -395,6 +397,10 @@ static nrfx_err_t twi_tx_start_transfer(twi_control_block_t * p_cb,

// In case TWI is suspended resume its operation.
nrf_twi_task_trigger(p_twi, NRF_TWI_TASK_RESUME);
+
+ if(p_twi == (NRF_TWI_Type*)0x40003000)
+ nrf_delay_us(300);
+
nrf_twi_task_trigger(p_twi, NRF_TWI_TASK_STARTTX);

(void)twi_send_byte(p_twi, p_data, length, &p_cb->bytes_transferred, no_stop);

Please note that the « if(p_twi == (NRF_TWI_Type*)0x40003000) » is there just because I want to affect TWI0 only, which is the one concerned by my specific design, and minimize any side effect on the rest of the system. This patch is definitely not a fix, just some hack.

Hopefully, you can help with this.

BTW, as I wrote, I am currently still using sdk15,0,0, maybe this issue is already fixed in 15,0,2.

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

Vincent Belaïche — Wed, 19 Sep 2018 12:20:10 GMT

Hello,

I have done some experiments, and I realized a few things.

First, as you remember I had a version of the FW, let us call it V0, in which I had no callback neither in running the program freely with just RTT logging, nor in debugging session, and a second version, let us call it V1, in which I had the callback when running in debugger but not when running the SW freely with just RTT logging.

So the first thing which I have understood is that in V0 there was a mistake of mine by which the NRFX_PRS_BOX_0_ENABLED, and NRFX_TWI0_ENABLED and TWI0_ENABLED flags were not dispatched to all the FW but only to the part which was calling and configuring the TWI0. This mistake may explain the problem, but not fully because when I placed some « #error Voilà » in the nrfx_twi.c code under condition of these flags I could observe that nrfx_twi.c had the flags.

Anyway, the problem still exists with V1, and that seems to be some real time issue in the way the TWI0 is configured. Probably there should be some « nrf_delay_us(…) » just before the « nrf_twi_task_trigger(p_twi, NRF_TWI_TASK_STARTTX) » possibly depending on the TWI configured speed.

As I could not see the registers under the debugger, because I cannot reproduce the bug this way, what I did is place some « memcpy(temp_twi_register_state,p_twi,sizeof(NRF_TWI_Type)); » just before the « nrf_twi_task_trigger(p_twi, NRF_TWI_TASK_STARTTX) ». Doing this created some delay before « nrf_twi_task_trigger(p_twi, NRF_TWI_TASK_STARTTX) » and that sufficed to make it work (ie that caused the call back to be called).

For your information, here is the register state dump:

<info> FOO: twi register state = [1420]:

<info> FOO: 0000000000000000000000000000000000000000000000000000000000000000

<info> FOO: 0100000000000000000000000100000000000000000000000000000000000000

<info> FOO: 0000000000000000000000000000000000000000000000000000000001000000

<info> FOO: 0000000000000000000000000000000000000000000000000000000000000000

<info> FOO: 0100000000000000000000000000000000000000000000000000000000000000

<info> FOO: 0000000000000000000000000000000000000000000000000000000000000000

<info> FOO: 05000000000000001b00000008000000ffffffffffffffff0000000000000000

<info> FOO: 0000000000006806000000000000000000000000000000000000000000000000

<info> FOO: 0000000000000000000000000000000000000000000000000200000000000000

<info> FOO: 0000000000000000000000000000000000000000000000000000000000000000

<info> FOO: 010000000000000069000000

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

haakonsh — Tue, 18 Sep 2018 13:36:14 GMT

We need the content of the registers before the TASKS_STARTTX is triggered, but after the driver has set up the transfer.

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

Vincent Belaïche — Mon, 17 Sep 2018 15:45:17 GMT

OK, I was a bit too quick in writing that it had worked. In fact there is exactly the same problem in the same conditions.

When I run the program with this sort of command line:

nrfjprog --reset && JLinkRTTLogger -Device nrf52840_XXAA -If SWD -Speed 4000 -RTTCHannel 0 /dev/stdout

then I get the problem occurring (ie my FreeRTOS queue is timed out, which calls the app error handler).

We are using SEGGER backend for the NRF LOGGER, and it seems that this is what creates the condition that makes the problem happen.

When I run the same program under the debugger (which is what I did to post the content of registers as you required), then I can get through the line at which the problem occurs without it occurring --- that is why I thought in my previous post that the problem had disappeared.

In fact it is still there but I was not in the conditions in which it happens.

Maybe I should push the TWI registers content to the logger so that we can see what is their content in the conditions when the problem happens.

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

Vincent Belaïche — Mon, 17 Sep 2018 14:59:38 GMT

Ooops… SOMETHING has happened, it has worked !

I must admit that it is not exactly the same FW as that on which I observed the issue when I opened the thread, I will try to make a git clone of the same version to see if I can reproduce the problem again…

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

Vincent Belaïche — Mon, 17 Sep 2018 14:52:46 GMT

To be more complete, I also printed the transfer descriptor, it is as follows (I just obfuscated the device address):

(gdb) print /x *p_xfer_desc
print /x *p_xfer_desc
$6 = {type = 0x2, address = 0x…, primary_length = 0x1, secondary_length = 0x1, p_primary_buf = 0x200041e3,
p_secondary_buf = 0x200041e0}

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

Vincent Belaïche — Mon, 17 Sep 2018 14:45:41 GMT

Hello,

Thank you vey much for the feedback, I will try to answer point by point.

[quote userid="13562" url="~/f/nordic-q-a/37581/dynamic-reconfiguration-of-peripheral-hw-from-twi-to-spi/148759"]Do you see any strange behavior on the TWI lines?[/quote]

Well, I cannot say this now, I need to make some setup so that I can observes the line on the scope, I am afraid I don't have easy easy test point to get them right away.

[quote userid="13562" url="~/f/nordic-q-a/37581/dynamic-reconfiguration-of-peripheral-hw-from-twi-to-spi/148759"]What is the state of the TWI0 registers before the STARTRX or TX is triggered?[/quote]

The first function that is called is nrfx_twi_xfer, when I am at line 601 of file nrfx_twi.c here is what I can print in gdb:

nrfx_twi_xfer (p_instance=0x1d210 <m_FOO_twi_transient_i2c>, p_xfer_desc=0x200041cc, flags=0)
at /Users/vincentbelaiche/Projects/biosency-fw_dev3.4/boraconnect-firmware/nrf-sdk/modules/nrfx/drivers/src/nrfx_twi.c:583
583 nrfx_err_t err_code = NRFX_SUCCESS;
(gdb) until
until
584 twi_control_block_t * p_cb = &m_cb[p_instance->drv_inst_idx];
(gdb) until
until
601 err_code = twi_xfer(p_cb, (NRF_TWI_Type *)p_instance->p_twi, p_xfer_desc, flags);
(gdb) print *p_cb
print *p_cb
$1 = {handler = 0x7461 <FOO_transient_twi_cb>, p_context = 0x20002790 <m_FOO_context_s>, int_mask = 0, xfer_desc = {
type = NRFX_TWI_XFER_TX, address = 0 '\000', primary_length = 0, secondary_length = 0, p_primary_buf = 0x0 <__isr_vector>,
p_secondary_buf = 0x0 <__isr_vector>}, flags = 0, p_curr_buf = 0x0 <__isr_vector>, curr_length = 0 '\000',
curr_no_stop = false, state = NRFX_DRV_STATE_POWERED_ON, error = false, busy = false, repeated = false,
bytes_transferred = 0 '\000', hold_bus_uninit = true}
(gdb) print /x *((NRF_TWI_Type *)p_instance->p_twi)
print /x *((NRF_TWI_Type *)p_instance->p_twi)
$3 = {TASKS_STARTRX = 0x0, RESERVED0 = 0x0, TASKS_STARTTX = 0x0, RESERVED1 = {0x0, 0x0}, TASKS_STOP = 0x0, RESERVED2 = 0x0,
TASKS_SUSPEND = 0x0, TASKS_RESUME = 0x0, RESERVED3 = {0x0 <repeats 56 times>}, EVENTS_STOPPED = 0x0, EVENTS_RXDREADY = 0x0,
RESERVED4 = {0x0, 0x0, 0x0, 0x0}, EVENTS_TXDSENT = 0x0, RESERVED5 = 0x0, EVENTS_ERROR = 0x0, RESERVED6 = {0x0, 0x0, 0x0, 0x0},
EVENTS_BB = 0x0, RESERVED7 = {0x0, 0x0, 0x0}, EVENTS_SUSPENDED = 0x0, RESERVED8 = {0x0 <repeats 45 times>}, SHORTS = 0x0,
RESERVED9 = {0x0 <repeats 64 times>}, INTENSET = 0x0, INTENCLR = 0x0, RESERVED10 = {0x0 <repeats 61 times>, 0x1,
0x0 <repeats 48 times>}, ERRORSRC = 0x0, RESERVED11 = {0x0 <repeats 14 times>}, ENABLE = 0x5, RESERVED12 = 0x0, PSEL = {
SCL = 0x1b, SDA = 0x8}, RESERVED13 = {0xffffffff, 0xffffffff}, RXD = 0x0, TXD = 0x0, RESERVED14 = 0x0, FREQUENCY = 0x6680000,
RESERVED15 = {0x0 <repeats 12 times>, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0}, ADDRESS = 0x0}
(gdb)

Please note that in the above I have renamed some of my symbols with …_FOO_… to be consistent with the beginning of this discussion.

[quote userid="13562" url="~/f/nordic-q-a/37581/dynamic-reconfiguration-of-peripheral-hw-from-twi-to-spi/148759"]Have you tried using the TWIM/TWIS drivers? As they use EasyDMA and PPI shortcuts they require less CPU resources, whom I assume you are in dire need of if your running an RTOS on top of the SoftDevice. [/quote]

No, I have not tried that yet, though it is a good idea certainly.

The FW which I am using is not the full application FW, it is a test FW with only the modules at stake. There is no SoftDevice in it, but the RTOS is there.

I must admit that the NRF_LOGGER is used and may take some resource, however I don't think that it is the root cause because for some other module with TWI interfacing in a similar way and quite intensive logging there is no problem.

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

haakonsh — Fri, 14 Sep 2018 09:18:52 GMT

The only two reasons I can think of is that the interrupts are disabled or the CPU is stuck in a higher priority ISR. The TWI peripheral should fire the ERROR event if any operation outside the spec is occuring.

Do you see any strange behavior on the TWI lines?

What is the state of the TWI0 registers before the STARTRX or TX is triggered?

Have you tried using the TWIM/TWIS drivers? As they use EasyDMA and PPI shortcuts they require less CPU resources, whom I assume you are in dire need of if your running an RTOS on top of the SoftDevice.

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

haakonsh — Fri, 14 Sep 2018 09:05:13 GMT

I've reported your issue to the SDK developers, but It will take some time before they can look into it. We are nevertheless very greatful for your report.

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

Vincent Belaïche — Wed, 12 Sep 2018 12:35:56 GMT

Just as a side comment, I am rather confident in the way that the TWI is configured, because I first did the experiment with two different peripherals, TWI1 and SPI0 and the legacy API. And in this case the TWI transfer works OK.

My problem occurred after porting to the new API, and trying to use the PRS stuff to share TWI0 + SPI0.

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

Vincent Belaïche — Wed, 12 Sep 2018 12:32:37 GMT

Hello,

Yes the NRF_PRS_BOX_0_ENABLED is set. This was anyway a good point to mention, as in the first place I did the mistake of not setting it. I have made a suggestion to improve the sdk_validation.h to that respect.

I think I have made some progress in understanding what happens.

First of all the twi_irq_handler is not called, I have tried with a debugger and a JLink, with putting a breakpoint on this function.

I also checked that p_cb->handler and p_cb->context are correctly set to my callback function (but anyway, that does not help as the irq handler is not called).

Then, I saw that when nrfx_twi_xfer is called by my FreeRTOS task, it calls in turn twi_xfer, which in turn calls twi_tx_start_transfer. In twi_tx_start_transfer, p_cb->int_mask is set to 0x286 which should be NRF_TWI_INT_STOPPED_MASK | NRF_TWI_INT_ERROR_MASK | NRF_TWI_INT_TXDSENT_MASK | NRF_TWI_INT_RXDREADY_MASK, and nrf_twi_int_enable(p_twi, p_cb->int_mask) is called.

However, I noticed that this call occurs after the call to (void)twi_send_byte(p_twi, p_data, length, &p_cb->bytes_transferred, no_stop). Hopefully it is not too late, and the interrupt is still pending.

Well, if there is any experiment (like reading some memory) you would like me to do, please feel free to ask !

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

haakonsh — Fri, 07 Sep 2018 12:26:38 GMT

Have you set NRFX_PRS_BOX_X_ENABLED ?

Another option is to uninitialize the TWI driver before initializing the SPI driver. If the both use the same instance number (0-2) they will in fact share the same peripheral and their drivers will not initialize unless the peripheral unless no other driver has claimed the instance. I believe this is what the PRS library does, only with semaphores and atomic operations. BOX 0 refers to SPIM0, SPIS0, TWIM0, TWIS0, SPI0, and TWI0.

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

Vincent Belaïche — Tue, 04 Sep 2018 17:28:42 GMT

Hello,

I tried to use the PRS library. I ported my entire peripheral chip handler to the new API, so that one just have to set the NRFX_PRS_ENABLED flag for the nrfx_prs_acquire to be called under the hood by nrfx_twi_init. I am using SDK 15,0,0.

It does not work for me, the call back passed to nrfx_twi_init is never called, and after the first call to nrfx_twi_xfer my OS task get stuck…

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

Vincent Belaïche — Mon, 03 Sep 2018 17:38:41 GMT

OK, after looking further into this matter, I sort of understood that

either you use the nrfx_glue.h that is in the nrf-sdk/integration/nrfx diretory, and then you use the legacy API and you have to call explicitly the nrfx_prs_acquire and nrfx_prs_release function.
or you copy the nrfx_glue.h template from nrf-sdk/modules/nrfx/templates to some places where the FW can find it, and you use the new API. With the new API you do not need to call explicitly the nrfx_prs_… stuff, because it does it by itself.

Now, my questions are:

Have I understood well ?
If yes, which way is better ?
And, just to minimize the migration effort, is it possible to use the new API just for one peripheral and the legacy one for others, and in this case what care should be taken ?

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

Vincent Belaïche — Fri, 17 Aug 2018 10:24:25 GMT

Thank you for the answer, by reading the presentation of this module, this seems to be the right answer…

RE: Dynamic reconfiguration of peripheral HW from TWI to SPI

mrono — Fri, 17 Aug 2018 10:12:31 GMT

I think this should be doable with the SDK's Peripheral Resource Sharing (PRS) module. If I have understood correctly the main purpose of the PRS module is to allow you to use shared resources like this.