Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defend against abnormal events #205

Open
nomis52 opened this issue Oct 3, 2015 · 4 comments
Open

Defend against abnormal events #205

nomis52 opened this issue Oct 3, 2015 · 4 comments

Comments

@nomis52
Copy link
Member

nomis52 commented Oct 3, 2015

One thing I found during testing today, if you disconnect the IC line, the unit 'locks up' when used as an RDM controller with one or more responders on the line. This is because without IC we never enter the STATE_C_RX_IN_DUB but the UART is still receiving and Transceiver_UARTEvent() is called repeatably.

This is symptomatic of a general class of 'abnormal' failures. If something happens that we don't expect, we should enter the ERROR state and reset the unit.

e.g.

case STATE_C_INITIALIZE:
case STATE_C_TX_READY:
case STATE_C_TX_DATA:
case STATE_C_TX_DRAIN:
case STATE_C_RX_WAIT_FOR_BREAK:
case STATE_C_RX_WAIT_FOR_MARK:
case STATE_C_RX_DATA:
case STATE_C_RX_WAIT_FOR_DUB:
case STATE_C_RX_IN_DUB:
case STATE_C_RX_TIMEOUT:
case STATE_C_COMPLETE:
case STATE_C_BACKOFF:
case STATE_R_INITIALIZE:
case STATE_R_RX_PREPARE:
case STATE_R_RX_BREAK:
case STATE_R_RX_MARK:
case STATE_R_RX_MBB:
case STATE_R_RX_DATA:
case STATE_R_TX_DATA:
case STATE_R_TX_DRAIN:
case STATE_R_TX_COMPLETE:
case STATE_ERROR:
case STATE_RESET:
  // Should never happen
  {}

That last line should handle the failure.

@Bartel-C8
Copy link

Bartel-C8 commented Sep 21, 2022

I keep getting stuck in

Changed to 10

Which is STATE_C_RX_WAIT_FOR_DUB. It seems that it never times out...
The device is also not responsive anymore via USB, it is completely frozen...

I am using the reference design:
https://docs.openlighting.org/ole/doc/latest/reference-design.html

Anyone using that as well?
Are the defines of app_settings.h still correct for ethernet_sk2? Especially the IC define?
https://github.com/OpenLightingProject/ja-rule/blob/master/boardcfg/ethernet_sk2/app_settings.h#L73

It happens when I start olad, which triggers a RDM discovery.
If I disconnect my fixture, it is fine.
The transceiver self-check passes. (But it does not use the same timers/IC).

Anyone can help me out? @nomis52 @peternewman ?

@Bartel-C8
Copy link

@peternewman : Do you have the OLA RDM test suite still running?

Is there any Ja-Rule board we can order somehow, alternatively, if the reference design is not supported?

@peternewman
Copy link
Member

@peternewman : Do you have the OLA RDM test suite still running?

Yeah, I ran some through a Number 1 at the recent Lille Plugfest seemingly without issues (aside from with the device under test). Is that what you meant?

Is there any Ja-Rule board we can order somehow, alternatively, if the reference design is not supported?

The company that made the original batch of Number 1's aren't doing so anymore unfortunately. The design is here, but I'm not sure if it includes a PCB layout:
https://github.com/OpenLightingProject/ja-rule/tree/master/hardware/number1

@Bartel-C8
Copy link

@peternewman , thanks for your reply. We've met actually in Lille ;-), I was the one of Constell8/KLSTR.

The hardware schematics are there of the Number1. But we bought the development kit of Microchip, which the Number1 was based upon. But can't get it working with that...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants