This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

twi fail in second msg attempt

hello

i am using nrf52832, with ble (s132 softdevice), pwm drv, saadc drcm uart, and using app_timers

i have added the twi drv to work with an expander for start.

this is how my function looks like

Fullscreen
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

this is where i call the function:

Fullscreen
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

first message gets ok, second fails (error 17) ->  [is there some file that shows what every error number is refering to ??? i could not find ]

this is my init:

Fullscreen
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

i have read in this forom that i should config some event handler in my init but it is not clear to me what should be done in this event handler because i have nointtention to creat some loop that waits for some 'OK' event

also, 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 ???

how can i solve this ?

Best regards

Ziv

  • 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. 

  • all together in main(). Having the soc hardware handle this all by itself isn't really possible

    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 ?

1 2