twi fail in second msg attempt

RE: twi fail in second msg attempt

ziv123 — Mon, 15 Jun 2020 13:34:19 GMT

[quote userid="2111" url="~/f/nordic-q-a/62583/twi-fail-in-second-msg-attempt/255040"]all together in main(). Having the soc hardware handle this all by itself isn't really possible[/quote]

i do not expect the hardware to deal with a malfunction if it accurse but to alert and maybe abort pervious operation, but like the saadc driver knows to read one pin (channel) and after finishing its readings move to the next defined pin and so on and can even trigger a high or low limit compar.. then i do belive some things can be done without CPU intervention on the driver side.. i understand that the current twi driver can not do that ?

RE: twi fail in second msg attempt

Kenneth — Mon, 15 Jun 2020 13:19:46 GMT

Feel free to modify this the best to your needs and requirement. It may be twi sensors that based on your experience malfunction, and you want to handle this gracefully in your application. You may for instance add a down counter in your while() loop, and that way get out of a stuck situation or your twi callback handler can handle a twi que, and thereby you may avoid having a while() all together in main(). Having the soc hardware handle this all by itself isn't really possible if you assume that a malfunction can occur, since the hardware will not be able to identify such an occurrence either. So you will need (at least the way I see it) add additional handling of errors and timeouts for transfer in your application, if based on your experience see that this occurs from time to time. My impression is that these kind of error occurs frequently during development due to timing constrains not followed, pull-ups not mounted, register access is not allowed or errors in twi transfers break for instance the usage of twi either on the master or slave, however once these have been identified during development, then simple while() loops do work.

RE: twi fail in second msg attempt

ziv123 — Mon, 15 Jun 2020 13:01:47 GMT

I am sorry if my replay maybe a bit rude but I wonder if you think I am stupid :/

i am sorry to say but the use of a bool flag in a while loop is not the most clever solution one can think of..

let's say that for some reason there is a malfunction in the twi tx and i never get the event of type ' NRF_DRV_TWI_EVT_DONE ', the way it is implemented in the example i get stuck in the while loop forever and i am sure my employer will not like that so much, also there is no functional difference if i wait in delay or wait in a loop, still my program is missing a whole many things that maybe happening now

this is why I asked if there is a way to let the "hardware" do that work ,of waiting and managing the send of the buffered msg, which is always a good practice in embedded

best regards

Ziv

RE: twi fail in second msg attempt

Kenneth — Mon, 15 Jun 2020 12:39:53 GMT

If you look at \examples\peripheral\twi_sensor you can for instance find how to use a 'm_xfer_done' flag to notify when the previous transaction is finished.

RE: twi fail in second msg attempt

ziv123 — Mon, 15 Jun 2020 12:32:00 GMT

hi Kenneth

i added 10 ms delay between one call to the next and i so everything passing good on the ociloscop

still, it is not something i want to do in my program to creat a delay or configure another timer just for the second twi tx, is there anyway to avoide that or any mechanism, like using the DMA as buffer for the next message and the driver will collect and transmit the msg from there once the first message receivs the desirable Ack ??

best regards

Ziv

RE: twi fail in second msg attempt

Kenneth — Mon, 15 Jun 2020 12:17:01 GMT

The first I would recommend it simply drag in the example code as-is from the nRF5 SDK twi example to check that it works as intended. For instance a logic analyzer is very valuable to check if data is sent and acked as intended. In your case you have set 'twi_handler' in nrf_drv_twi_init() so this means that the 'twi_handler()' should execute after transfer to indicate if data was sent successfully or not. The error code 17 from nrf_drv_twi_tx() I can see from nrf_drv_twi.h is NRF_ERROR_BUSY, which make sense since the previous call is not yet finished here. Make sure you have included all 'TWI' defines from the nRF5 SDK twi example sdk_config.h to your sdk_config.h. Make sure that the TWI pins have pull-up resistors.

RE: twi fail in second msg attempt

ziv123 — Mon, 15 Jun 2020 08:50:17 GMT

one more this .. when i run in debug mode i see that i am not entering the event handler at all so it is not so clear to me what i am doing wrong ???