nrf_twi_mngr_perform blocking

RE: nrf_twi_mngr_perform blocking

Rune Holmgren — Fri, 09 Mar 2018 09:52:49 GMT

Unrelated to the bug we are working on I just wanted to mention this project made by a Nordic engineer which may be of interest to you: https://github.com/Martinsbl/nrf5-mpu-examples

Best regards,
Rune Holmgren

RE: nrf_twi_mngr_perform blocking

Jason Hendrix — Fri, 09 Mar 2018 04:33:21 GMT

Thanks for that Rune. A timeout of 5 is equal to 2.5 ms, which is enough time for 100 bytes on the I2C running at 400KHz (if I'm not mistaken). That seems like plenty of time to complete a single byte read (of course there's a couple of bytes of overhead and the slave can delay the return value but I haven't seen anything on the order of a millisecond...)

That said, I agree that I can't trigger the fault with a longer delay.

I'd like to look at this some more because I'm fairly certain that I had this problem without hitting my timeout function in my application code. I'll get back to you in a few days.

RE: nrf_twi_mngr_perform blocking

Rune Holmgren — Thu, 08 Mar 2018 16:13:14 GMT

Hi,

Thanks for your patience. I was able to borrow a sensor from a colleague who happened to have one (not quite the same model, but it responded to the TWI commands so close enough). With that, I was able to reproduce the issue and debug it. Below you can see a screenshot of the crashed state where the device hardfaulted shortly after attempting to schedule a TWI operation.

I did some further digging, and it seems the device has a timeout of only 5 set two places in the variable "TWITimeout". When this timeout is hit the device is not able to recover correctly. Simply setting this timeout to 50 instead of 5 seems to have resolved the issue for me. I don't see a reason it needs to be as low as 5, so you can try to experiment with this value to find the lowest stable value.

(A note, I would recommend putting this number in a define rather than having a number hardcoded in two places)

Best regards,
Rune Holmgren

RE: nrf_twi_mngr_perform blocking

Jason Hendrix — Tue, 06 Mar 2018 16:37:15 GMT

Hi Rune,

You should be able to see the issue with any I2C target. The readme has some notes on porting. If you're co-located with Kenneth, he is working on another issue (probably related) and has this MPU part on order. Perhaps you can share:

devzone.nordicsemi.com/.../i2c-reads-stuck

RE: nrf_twi_mngr_perform blocking

Rune Holmgren — Tue, 06 Mar 2018 12:23:38 GMT

Hi,

Sorry for the delay, have you figured this issue out in the meanwhile? Let me know if you have any further details and still need help with this.

I had a look at your project, and I can't spot any cause of the issue from looking at the source code. Unfortunately, I do not have an MPU6050 available so I am unable to actually run and debug your project on actual hardware. I had a peek at some projects using motion control with our chip and found that the MPU-9250 has at least been used successfully. It looks similar enough that I assume the MPU6050 shouldn't be an issue if you can find the bug in your firmware.

Best regards,
Rune Holmgren

RE: nrf_twi_mngr_perform blocking

Rune Holmgren — Wed, 21 Feb 2018 13:55:30 GMT

Thank you. I have been talking a bit with the SDK team regarding this, and I'll look into the project you sent me and follow it up with the SDK team. Hopefully, we will figure out what is the issue here. It may be a few days.

Best regards,
Rune Holmgren

RE: nrf_twi_mngr_perform blocking

Jason Hendrix — Wed, 21 Feb 2018 06:35:33 GMT

Hi Rune, I'm uploading a project that can be used to recreate the issue. The README provides more details.devzone.nordicsemi.com/.../Debug_5F00_Test.zip

RE: nrf_twi_mngr_perform blocking

Jason Hendrix — Wed, 14 Feb 2018 23:40:22 GMT

HI Rune,

I've been delayed slightly - will get back to this in about a week.

RE: nrf_twi_mngr_perform blocking

Jason Hendrix — Thu, 08 Feb 2018 17:54:39 GMT

HI Rune,

Here are a couple of pictures of the fault in action. I'll try to pin it down better, but from the pictures you can see that we had a TWIM interrupt and are scheduling the next transaction. However, the next (current) transaction points to a read descriptor on the stack, which is corrupted, as you can see by the TWI cfg. I believe a couple of weeks ago I was able to catch a "blocking" twi_perform that actually completed a different transaction when it returned. That's why it seems to me that the perform waited on a transaction that was already in the queue, leaving the transaction I wanted to wait on (and which had descriptors on the stack) in the queue. Then when this interrupt occurs, and the descriptor gets pulled from the queue, my blocking register read function has already gone out of scope. That's all just my hypothesis. I'll try to get some more concrete evidence, or something more repeatable. I'm also working on this issue and can probably use that test setup for both issues.

RE: nrf_twi_mngr_perform blocking

Rune Holmgren — Thu, 08 Feb 2018 15:30:01 GMT

I am not 100% sure I understand what your problem is, the description of what you are doing seems like a correct way queue and perform blocking and non-blocking TWI operations. Let me know if I misunderstood you.

It is perfectly fine to mix "schedule" and "perform" calls to the nrf_twi_mngr. Schedule calls will not block but return immediately. Scheduled operations will be performed when the bus is available. Perform calls can queue one or more operations and will block until the operation is done. Perform calls should not return early, so you shouldn't be able to end up out of scope.

Take care to check all return values from these API calls. Error codes have to be handled, or you may experience packets never being sent.

Best regards,
Rune Holmgren