deltaphi / c6021light Goto Github PK

Hi,

Love the work you are doing on this. I've ordered a blue pill to have a look at this and I did not connect anything but one 6040 keyboard. Somehow after the first press on the 6040 it gets stuck and keeps sending the last i2c message with a one-second interval. Reading Dr. Köning's site I guess that it is waiting for the acknowledgment.

2C RX: [0x7f 0x20 0x8] - Keyboard: 0, Decoder: 0, (Turnout: 0, Direction: RED  , Power: ON )
Accessory Switch. Details: Turnout:     0x3800, Human Value: 14337, Position: 0 (off, round, red) Power: 1 (on, button press)

Can you confirm that the i2c acknowledgment is only sent when there is a CAN device responding?
Or am I missing something here?

My Connections are:
- Blue Pill GPIO6 (PB6) <-> 6040 2b
- Blue Pill GPIO7 (PB7) <-> 6040 4b
- 8V                         <-> 6040 16b
- GND                      <-> 6040 GND

Blue Pill get 5V from FDTI and all GNDs are tied together.

When a Keyboard with address > 0 sends a request for turnout (e.g., Turnout 98), c6021light does not respect the keyboard address properly and instead sees a request for the same button on a Keyboard with Address 0 (e.g., Turnout 2 in this example). Responses are generated for the seen Keyboard not the actual Keyboard, locking the Keyboard in a loop.

When downloading the CanDB, the blink codes of the Status LED should indicate whether...

• The c6021light is currently requesting a download but not receiving data,
• The c6021light is receiving the engine list,
• The c6021light is receiving engines.

Currently, the LED changes only its frequency to indicate OK/ERROR/DOWNLOADING. In addition, the duty cycle could be adjusted to that, e.g., requesting is a short blip where receiving is a longer blip.

Functions F0..F4 are forwarded from CAN to LocoNet as expected. Functions F5+ are not forwarded.

Looking at a trace of LN messages shows that for F5, instead of a SND message a DIRF message is sent.

The LocoNet personal edition only specifies commands up to F8. It seems LN is capable of higher functions as well. The following encoding was reverse-engineered by snooping on the LN-T port of an Intellibox II:

0xA3 slot_id 0b0000_[F12:F9 in Bits3:0]

0xD4 0x20 slot_id  0x8 0b0[F19:F13 in Bits 6:0]
0xD4 0x20 slot_id  0x9 0b0[F27:F21 in Bits 6:0]
0xD4 0x20 slot_id  0x5 0b0[F28|F20 in Bits 6:5]0_0000

Can be done using undocumented commands: https://stummiforum.de/viewtopic.php?p=2233605#p2233605

On I2C, responses are different between "STOP" mode and "GO" mode. Currently, c6021light behaves as if there was a perpetual "GO" mode.

Recommended behavior:

• On Request from I2C, c6021 stores the request and forwards the request on CAN.
• When a confirmation is received from CAN, the confirmation is forwarded to I2C. If the confirmation matches the stored request, the stored request is deleted.
• When a request is stored and no confirmation is received for 1ms, send a "STOP"-style response to the 6040.

When powering on the c6021light and an MS2 at the same time (say, through a switchable powerbar), the Engine DB Download on the c6021light gets stuck. A manual reset of the board is required. Starting the download through the serial interface does not work.

Original report by @GBert

Zur LED:
Wir haben glaube ich das schon mal diskutiert. Start/Stopp Zustand
fände ich besser auf der im Layout vorgesehenen Led. Die Led auf
dem Blupill sollte IMHO als Anzeige des allgemein Zustands verwendet
werden. Ich fände hier einen Heartbeat angebracht:

void sys_tick_handler(void) {
counter++;
if (counter == 100)
gpio_set(GPIOC, GPIO13);
if (counter == 220)
gpio_clear(GPIOC, GPIO13);
if (counter == 400)
gpio_set(GPIOC, GPIO13);
if (counter == 520)
gpio_clear(GPIOC, GPIO13);
if (counter > 999)
counter = 0;
}

So, oder so ähnlich.

Reported by @glaserf. When downloading the CanEngineDB either through the StateMachine or the CLI, the download requests the same engines over and over again.

Log by @glaserf:

Connect6021Light Initializing...
Reading Configuration.
Setting up callbacks.
Ready!
c6021light > Storing Engine 103 220-0 DB AG
Storing Engine 150 124-6 DB
Storing Engine BR 101 ADtranz
Storing Engine BR 103 137-6
Storing Engine BR 101 ADtranz
Storing Engine BR 103 137-6
Storing Engine BR 101 ADtranz
Storing Engine BR 103 137-6
Storing Engine BR 101 ADtranz
Storing Engine BR 103 137-6
Storing Engine BR 101 ADtranz
Storing Engine BR 103 137-6
Storing Engine BR 101 ADtranz

Personally, I observed no issue when downloading two engines. Issue may be related to having more than two engines or to having an odd number of engines.

An I2C RX Message for Turnout 3 on the first Keyboard looks as follows (correct):

I2C RX: [0x7f 0x20 0xd] - Keyboard: 0, Decoder: 2, (Turnout: 2, Direction: GREEN, Power: ON )

When the c6021light sends a response (that is correctly interpreted by the correct Keyboard), it is incrrectly logged as:

I2C TX: [0x20 0x7f 0xd] - Keyboard: 15, Decoder: 2, (Turnout: 242, Direction: GREEN, Power: ON )

Spotted problem: The "Keyboard" value is taken from the sender, which in this case is not a Keyboard but the c6021light. The "Turnout" contains the same input as the "Keyboard" value and is thus similarly incorrect.

Original report by @GBert

Eine kleine Verbesserung zum CLI hätte ich gerne noch integriert.
Wenn man einen Befehl absetzt wird kein Zeilenvorschub gemacht.
Man sieht also nicht, was man eingegeben hat. Kannst Du das noch einbauen ?

Original report by @GBert

The Start/Stop state should be displayed using the off-board LED.

Under moderately heavy load, e.g., pressing turnout buttons 1-8 at only a few 100 ms intervals, some I2C messages appear to go missing.

Observation: After switching the second or third turnout, a Keyboard does not respond immediately to further button presses. IT usually takes about one second for a button press to be processed, before another button can be pressed.

Suspected reasons:

• STM32 loses I2C messages on RX.
• STM32 is delayed sending response messages.

Might have to do with LocoNet integration?

Furn on a Function (e.g., F1) on a CAN control device. A LocoNet device sees the function change. Turn off the Function from the LocoNet device. The function change is not seen by the CAN control device.

Turn the function on and off again on the LocoNet device. Now the CAN control device sees the change.

It seems speed levels requested from LN get answered with the level below. This leads to a "stiff" control behavior when increasing the speed of an engine; you basically have to beat the speed of the bus. When decelerating, slowing down is consequently accelerated by a factor of 2. Here is an example, RX are requested speed steps from LN:

LN RX:  a0 1 4 5a [OPC_LOCO_SPD] Slot: 1 Speed: 4
LN TX:  a0 1 3 20 [OPC_LOCO_SPD] Slot: 1 Speed: 3
LN RX:  a0 1 5 5b [OPC_LOCO_SPD] Slot: 1 Speed: 5
LN TX:  a0 1 4 20 [OPC_LOCO_SPD] Slot: 1 Speed: 4
LN RX:  a0 1 6 58 [OPC_LOCO_SPD] Slot: 1 Speed: 6
LN TX:  a0 1 5 20 [OPC_LOCO_SPD] Slot: 1 Speed: 5
LN RX:  a0 1 7 59 [OPC_LOCO_SPD] Slot: 1 Speed: 7
LN TX:  a0 1 6 20 [OPC_LOCO_SPD] Slot: 1 Speed: 6
LN RX:  a0 1 7 59 [OPC_LOCO_SPD] Slot: 1 Speed: 7
LN RX:  a0 1 8 56 [OPC_LOCO_SPD] Slot: 1 Speed: 8
LN TX:  a0 1 7 20 [OPC_LOCO_SPD] Slot: 1 Speed: 7
LN RX:  a0 1 8 56 [OPC_LOCO_SPD] Slot: 1 Speed: 8
LN RX:  a0 1 9 57 [OPC_LOCO_SPD] Slot: 1 Speed: 9
LN TX:  a0 1 8 20 [OPC_LOCO_SPD] Slot: 1 Speed: 8

As a consequence, an engine will lose one speed step per LN refresh cycle and will eventually stop:

LN RX:  a0 1 8 56 [OPC_LOCO_SPD] Slot: 1 Speed: 8
LN TX:  a0 1 7 20 [OPC_LOCO_SPD] Slot: 1 Speed: 7
- pause -
LN RX:  a0 1 7 59 [OPC_LOCO_SPD] Slot: 1 Speed: 7
LN TX:  a0 1 6 20 [OPC_LOCO_SPD] Slot: 1 Speed: 6
- pause -
LN RX:  a0 1 6 58 [OPC_LOCO_SPD] Slot: 1 Speed: 6
LN TX:  a0 1 5 20 [OPC_LOCO_SPD] Slot: 1 Speed: 5
- pause -
LN RX:  a0 1 5 5b [OPC_LOCO_SPD] Slot: 1 Speed: 5
LN TX:  a0 1 4 20 [OPC_LOCO_SPD] Slot: 1 Speed: 4
- pause -
LN RX:  a0 1 4 5a [OPC_LOCO_SPD] Slot: 1 Speed: 4
LN TX:  a0 1 3 20 [OPC_LOCO_SPD] Slot: 1 Speed: 3
- pause -
LN RX:  a0 1 3 5d [OPC_LOCO_SPD] Slot: 1 Speed: 3
LN TX:  a0 1 2 20 [OPC_LOCO_SPD] Slot: 1 Speed: 2
- pause -
LN RX:  a0 1 2 5c [OPC_LOCO_SPD] Slot: 1 Speed: 2
LN TX:  a0 1 1 20 [OPC_LOCO_SPD] Slot: 1 Speed: 1
- pause -
LN RX:  a0 1 1 5f [OPC_LOCO_SPD] Slot: 1 Speed: 1
LN TX:  a0 1 0 20 [OPC_LOCO_SPD] Slot: 1 Speed: 0
- pause -
LN RX:  a0 1 0 5e [OPC_LOCO_SPD] Slot: 1 Speed: 0
LN TX:  a0 1 0 20 [OPC_LOCO_SPD] Slot: 1 Speed: 0

As reported by user markra in the stummiforum, on the first version of the PCB, the RX and TX lines for the serial header seem to be swapped.

Lines are not swapped when using a CH340.

Expected behavior:

• No device connected to I2C, operation happens on other busses.
• Device is connected to I2C
• Device starts operating normally.

Actual behavior:
Device appears not to communicate after being connected (no reaction to actions on other busses, no messages forwarded to other busses).

Likely explanation is that the I2C ISR gets stuck in an error state, blocking further communication.

The presence of C32 in the schematic converts the LnTx level to a peak, thus breaking LocoNet bus control for the STM32. In current vrsions, C32 must not be populated. In future versions, C32 should be removed.