HT16K33 fault stops program execution

[pirvcb]

Hello there!
I'm looking for a solution to solve this problem.
If the HT16K33 controller gets disconnected from the micro for any reason, when you call its Component during the program, the microcontroller stuck waiting for a reply by I2C protocol.
There is a way to recovery out, a time limit or so, to fix this ""bug""?
I mean, i need that the application don't stop itself in case of I2C fault.
Thnks!

[chipfryer27]

Hi

I don't know your processor or much about that controller but from the sounds of it then it may benefit from using a Watchdog Timer (WDT).

If enabled then you have to insert instructions to reset the WDT every so often within your program, which FC can handle. If you don't reset or if your program gets stuck or trapped then the WDT will expire and reset the processor starting execution from the beginning. If resetting is acceptable then remember to include code at the beginning of your program to initialise variables and set ports to a known and desired state.

Depending on your chip the WDT period can be from a few mS to many, many seconds.

Hope this helps

Regards

[pirvcb]

Thanks for your reply. WhatchDog is not a solution in my case. I dont need reboot the micro, i have to step over, going on with the code.
ATMEGA 2560 is the choiced platform.

[LeighM]

Seems odd to lockup on I2C, could you post your program?
That would be of help to us.
If it's occasional, it could be hardware/PSU related, in which case, as already suggested, a watchdog is the solution.
Thanks

[chipfryer27]

Hi

It's been a while since I used i2c but doesn't the transmitbyte command return an answer (0/1).

If the danger is the target being inadvertently unplugged, perhaps first send a "test" byte and if no reply branch to an error handling routine?

Regards

[pirvcb]

Here the sample code.
When HK Macro icon is disabled it works, blinking Port_B led.
In real hardware, if HK controller gets disconnected, the code execution looks up.

Also, there is another little problem.
As you can see, i have created a time base toggling the variable tick inside an interrupput and increasing the real time variable " time ", outside the interrupt.
If i increase directly the variable time just inside the interrupt, i get an erratic result in port_b timing after some cycles.
Some cycle, led blinks, sometime, in a random way, more short or so. When i give more load to the main loop, this random error goes to disappers. I cant figure out where the point is....
Tried out in both ATMEGA 328 and 2560. Both same results. Tried also in Flowcode V6. Same situation.

The attached exmples are saved for Arduino Uno R3.

THE FILE ERRATIC CORRECTED DOES NOT WORK AS NEEDED
SOLUTIN IS POSTED IN THE LAST POST

[pirvcb]

Well, fixed by myself the second problem. Adding a variable inside the interrupt and copy the value of the incremented variable in it fix the erratic behavoir.
Attached.

The first problem is still up here....

[LeighM]

If the HT16K33 controller gets disconnected from the micro for any reason

Do you mean the "shield" is removed from the Arduino?
If so, it could be that, if the I2C pull-up resistors are on the shield board, then their removal could be causing the issues.
If disconnection of the hardware is a known scenario,
then you need to ensure that there are still pull-up resistors attached to the I2C clock and data pins of the processor.

[pirvcb]

FANTASTIC!
I'll try as soon as possible and i'll report here.
Thank you!

[chipfryer27]

Hi

Following on from Leigh, I googled that Arduino as I'm not too familiar with it (but I still intend to dabble) and it appears (depending on posts) it has it's own onboard i2c pullups independent to sensor/shield. However many posts on forums talk of instability and lockup with i2c much as you are experiencing. Recommendations seem to revolve around keeping the i2c connections short and avoiding any crosstalk / noise (generally a good idea in any case).

I'm not sure of your application. Is your sensor / shield supposed to be permanently attached or is it supposed to be removable at will? If the latter you will perhaps need to test for its presence before issuing commands. If the former then as Leigh suggests, it may be a good idea to check functionality for i2c pullups as the posts I've read suggest some issues.

Regards

[pirvcb]

Putting pullup resistors on the mcu card soplves partially the fault by unaspected disconnection. Anyway, if for some event, the Holtek device can't receive the waited ACK by the mcu, it remains with a line LOW, and this stops again the MCU. One solution, could be set a flag before and resetting it after the Holtek macro. Then activate an ionterrupt that after some time, i mean 100ms or less, it depends at wich speed is set, will check the flag and, if found it wrong, disconnect the power from the Holtek card. This will resume HIGH the line (by the pullup resistors) and consequentially revoer the MCU to go on by its program.
I have also tried putting 2 1nF caps in parallel to data and clock lines to try worse condition.
Results are:
line speed goes down to max 60Khz;
With 2k as pullup resistor, line speed goes back to max 250khz speed.

This means that if you use 2k as pullup resistor and 100khz as speed, you're pretty sure to get a rock solid line.

[pirvcb]

ABOUT ERRATIC BEHAVOIR as i wrote in previous post....
The better soltion that i had found solution is attached here.
In the ERRATIC CORRECTED snippet, things was ok on AT328P but again erratic in mega 2560.
The Macro Component TIMER inside flowcode works ok but is cpu angry, so seems ok if you need more precison and dont have an heavy load by the code execution.
So i managed other try and found that the more inexpensive cpu cicles seems be that i post attached.