SDK 14.2.0: Reset on nrf_twi_mngr_perform(), TWI transaction memory messed up.

RE: SDK 14.2.0: Reset on nrf_twi_mngr_perform(), TWI transaction memory messed up.

Eliot Stock — Thu, 30 Aug 2018 21:15:56 GMT

I carried on with the SDK migration and noticed a completely unrelated problem, that my log message prefixes (the module names declared in each source file) were not making it through to the logs. Instead, only one of the module names was appearing for log messages from every module. I had already fixed the SDK 14.2.0 bug about the gcc linker script on log_const_data. Digging a bit deeper I found a devzone post about the same issue with log_dynamic_data, which I hadn't fixed. When I fixed that, suddenly the nrf_twi_mngr_perform() call worked.

This is horrible "action at a distance" and I'd really like to understand it better. It's only by blind luck that I was able to fix it and I need to know how a more experienced engineer than me would have debugged this.

RE: SDK 14.2.0: Reset on nrf_twi_mngr_perform(), TWI transaction memory messed up.

Eliot Stock — Thu, 30 Aug 2018 20:42:44 GMT

Also, you shouldn't need to compile my project because I provided hex files in the case. I'd get this running on a DK, but I don't think there's a TWI device on there.

RE: SDK 14.2.0: Reset on nrf_twi_mngr_perform(), TWI transaction memory messed up.

Eliot Stock — Thu, 30 Aug 2018 20:40:08 GMT

No, I'm not able to execute nrf_drv_twi_init() without getting a reset. Yes, the reset is part of nrf_twi_mngr_perform(), because that calls nrf_drv_twi_init() when it thinks the config has changed since the last call to it. Yes, I've tried to debug the nrf_queue code. See my comments added in nrf_twi_mngr_schedule() - the internal transaction's required config is null (good) before pushing onto the queue. Once it's on the queue it's hard to debug, because the queue code knows nothing about the types of the elements, but I do see that when popping the element off the queue, nrf_queue_generic_pop() thinks the element size in only 4 bytes. It can't be - see the nrf_twi_mngr_transaction_t type. I also note from my map file that m_twi and m_twi_queue are in flash, not RAM. Not sure if that's expected.

RE: SDK 14.2.0: Reset on nrf_twi_mngr_perform(), TWI transaction memory messed up.

Jørgen Holmefjord — Thu, 30 Aug 2018 14:46:25 GMT

I'm a bit confused. Are you not able to execute nrf_drv_twi_init? In your initial post you wrote that you got a reset on nrf_twi_mngr_perform. Have you tried to debug the application through nrf_queue_push and nrf_queue_pop functions to see exactly where the address is changed? I'm having some issues trying to compile your project, and I do not have the required sensors to test it with anyway. I'm not able to reproduce this issue with the TWI manager example in the SDK, which also use NULL as value for config parameter passed to nrf_twi_mngr_perform.

RE: SDK 14.2.0: Reset on nrf_twi_mngr_perform(), TWI transaction memory messed up.

Eliot Stock — Tue, 28 Aug 2018 16:44:44 GMT

Yes, the address is changed when the transaction is popped.

I'm able to execute nrf_drv_twi_uninit() but not nrf_drv_twi_init(), because the config passed in there is in the wrong memory. The reset happens on the nrf_drv_twi_init() call (these are in start_pending_transaction()).

RE: SDK 14.2.0: Reset on nrf_twi_mngr_perform(), TWI transaction memory messed up.

Jørgen Holmefjord — Tue, 28 Aug 2018 13:30:45 GMT

[quote user=""]After it's popped off the queue the transaction's required config is at a weird address in memory[/quote]

Is the address changed when the transaction is popped at nrf_twi_mngr.c:147, i.e., before it is assigned the default config at line 167?

Sounds like a hardfault due to an invalid address access. To which exact line are you able to step until?

RE: SDK 14.2.0: Reset on nrf_twi_mngr_perform(), TWI transaction memory messed up.

Eliot Stock — Tue, 28 Aug 2018 07:36:52 GMT

Added the whole codebasse in case 212942.