Failed to process DCC data

[murarduino]

I use ESP32 as the decoder. IDF architecture +Arduino components. DCC++ EX for command station, and UART serial port for command input monitoring.
I plugged the decoder into the PROG track and tried to respond to the ACK using the motor drive (motor works fine)

` void notifyCVAck(void)

{ ESP_LOGI(LOGTAG_DCC, "notifyCVAck");

MOTOR_Ack();

}

void MOTOR_Ack(void)
{
ledcWrite(MOTOR_PWM_CH_B, 0);
ledcWrite(MOTOR_PWM_CH_A, 240); vTaskDelay(6 / portTICK_PERIOD_MS);
ledcWrite(MOTOR_PWM_CH_A, 0);

}
`
No response, no output from ESP_LOG

I tried to read the DCC package again:

`void notifyDccMsg(DCC_MSG *Msg)
{
ESP_LOG_BUFFER_HEXDUMP("DCC_MSG",Msg->Data,Msg->Size,ESP_LOG_INFO);

}
`

Power on PROG (EX command<1>), with result:

I (165159) DCC_MSG: 0x3ffb2e22 ff 00 ff |...| I (165169) DCC_MSG: 0x3ffb2e22 ff 00 ff |...| I (165179) DCC_MSG: 0x3ffb2e22 ff 00 ff |...| I (165189) DCC_MSG: 0x3ffb2e22 ff 00 ff |...| I (165199) DCC_MSG: 0x3ffb2e22 ff 00 ff |...|

Feel like NMRA DCC can receive DCC signal, but can't process it, or am I wrong? Please advise.

[murarduino]

The decoder accesses the MAIN track. Perform any action using WebThrottle-EX, result:
I (57359) DCC_MSG: 0x3ffb2e22 00 00 00 |...| I (57369) DCC_MSG: 0x3ffb2e22 00 00 00 |...| I (57379) DCC_MSG: 0x3ffb2e22 00 00 00 |...| I (57389) DCC_MSG: 0x3ffb2e22 00 00 00 |...| I (57399) DCC_MSG: 0x3ffb2e22 00 00 00 |...|

[murarduino]

test Code:
`#include "Arduino.h"
#include "NmraDcc.h"
#include "esp_log.h"

#define LOGTAG_DCC "DCC"
#define DCC_PIN 4

#define MOTOR_PWM_CH_A 0
#define MOTOR_PWM_CH_B 1
#define CONFIG_PWM_A_PIN 8
#define CONFIG_PWM_B_PIN 7
#define DEFAULT_DECODER_ADDRESS 3

struct CVPair
{
uint16_t CV;
uint8_t Value;
};

// Default CV Values Table
CVPair FactoryDefaultCVs [] =
{
// The CV Below defines the Short DCC Address
{CV_MULTIFUNCTION_PRIMARY_ADDRESS, DEFAULT_DECODER_ADDRESS},

// These two CVs define the Long DCC Address
{CV_MULTIFUNCTION_EXTENDED_ADDRESS_MSB, CALC_MULTIFUNCTION_EXTENDED_ADDRESS_MSB(DEFAULT_DECODER_ADDRESS)},
{CV_MULTIFUNCTION_EXTENDED_ADDRESS_LSB, CALC_MULTIFUNCTION_EXTENDED_ADDRESS_LSB(DEFAULT_DECODER_ADDRESS)},

// ONLY uncomment 1 CV_29_CONFIG line below as approprate
// {CV_29_CONFIG, 0}, // Short Address 14 Speed Steps
{CV_29_CONFIG, CV29_F0_LOCATION}, // Short Address 28/128 Speed Steps
// {CV_29_CONFIG, CV29_EXT_ADDRESSING | CV29_F0_LOCATION}, // Long Address 28/128 Speed Steps
};

void Motor_init(void)
{
ledcSetup(MOTOR_PWM_CH_A, 8000, 8);
ledcAttachPin(CONFIG_PWM_A_PIN, MOTOR_PWM_CH_A);
ledcWrite(MOTOR_PWM_CH_A, 0);

ledcSetup(MOTOR_PWM_CH_B, 8000, 8);
ledcAttachPin(CONFIG_PWM_B_PIN, MOTOR_PWM_CH_B);
ledcWrite(MOTOR_PWM_CH_B,0);

};

void MOTOR_Ack(void)
{

ledcWrite(MOTOR_PWM_CH_B, 0);
ledcWrite(MOTOR_PWM_CH_A, 240); 
vTaskDelay(6);
ledcWrite(MOTOR_PWM_CH_A, 0);

};

void notifyCVAck(void)
{
ESP_LOGI(LOGTAG_DCC, "notifyCVAck");
MOTOR_Ack();
};

uint8_t FactoryDefaultCVIndex = 0;

void notifyCVResetFactoryDefault()
{
// Make FactoryDefaultCVIndex non-zero and equal to num CV's to be reset
// to flag to the loop() function that a reset to Factory Defaults needs to be done
FactoryDefaultCVIndex = sizeof(FactoryDefaultCVs)/sizeof(CVPair);
};

void notifyDccMsg(DCC_MSG *Msg)
{
ESP_LOG_BUFFER_HEXDUMP("DCC_MSG",Msg->Data,Msg->Size,ESP_LOG_INFO);
};
NmraDcc Dcc;

extern "C" void app_main()
{
initArduino();
Dcc.pin(DCC_PIN,0);
Dcc.init( MAN_ID_DIY, 10, FLAGS_MY_ADDRESS_ONLY | FLAGS_AUTO_FACTORY_DEFAULT, 0 );
while (1)
{
Dcc.process();
vTaskDelay(10);
}

}`

[murarduino]

open DCC_DEBUG，Connect the four indicator LEDs（ 33, 25, 26, 27） to execute the PROG command, but the indicator does not show anything

[kiwi64ajs]

A few thoughts: 1) I assume the decoder works enough to control the motor from a throttle, so the DCC Interface Hardware is working, and you have an external Pull-Up on the DCC Input. Is that a correct assumption? 2) You’re attempting to use the motor load as the DCC ACK, using the following code: void MOTOR_Ack(void) { ledcWrite(MOTOR_PWM_CH_B, 0); ledcWrite(MOTOR_PWM_CH_A, 240); vTaskDelay(6); ledcWrite(MOTOR_PWM_CH_A, 0); }; A) The function needs to be called: “notifyCVAck” for the weak reference mechanism to find it and call it. B) I believe the line: ledcWrite(MOTOR_PWM_CH_A, 240); will generate a PWM signal on the MOTOR_PWM_CH_A pin, which may or may not turn on the motor when you think it should. I suggest you set the PWM value to fully on, which is maybe 255 - I don’t know, as it will depend on the resolution of the PWM generator behind the ledcWrite() function. C) I suggest making the DCC ACK a little longer than 6ms - say 10 - 12ms to be sure. D) You don’t seem to be calling your void Motor_init(void) function so none of the ledc hardware init is being done. 3) If the above doesn’t work, then I suggest you prove your hardware and software first by using the normal Arduino IDE and make sure you’re not introducing some subtle differences by using the hybrid IDF environment. HTH Alex Shepherd

…

On 1/08/2023, at 1:10 AM, murarduino ***@***.***> wrote: open DCC_DEBUG，Connect the four indicator LEDs（ 33, 25, 26, 27） to execute the PROG command, but the indicator does not show anything — Reply to this email directly, view it on GitHub <#74 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5Y53LOJLNCFRP7R5KVIDTXS6VDJANCNFSM6AAAAAA244SR2A>. You are receiving this because you are subscribed to this thread.

[murarduino]

A few thoughts: 1) I assume the decoder works enough to control the motor from a throttle, so the DCC Interface Hardware is working, and you have an external Pull-Up on the DCC Input. Is that a correct assumption? 2) You’re attempting to use the motor load as the DCC ACK, using the following code: void MOTOR_Ack(void) { ledcWrite(MOTOR_PWM_CH_B, 0); ledcWrite(MOTOR_PWM_CH_A, 240); vTaskDelay(6); ledcWrite(MOTOR_PWM_CH_A, 0); }; A) The function needs to be called: “notifyCVAck” for the weak reference mechanism to find it and call it. B) I believe the line: ledcWrite(MOTOR_PWM_CH_A, 240); will generate a PWM signal on the MOTOR_PWM_CH_A pin, which may or may not turn on the motor when you think it should. I suggest you set the PWM value to fully on, which is maybe 255 - I don’t know, as it will depend on the resolution of the PWM generator behind the ledcWrite() function. C) I suggest making the DCC ACK a little longer than 6ms - say 10 - 12ms to be sure. D) You don’t seem to be calling your void Motor_init(void) function so none of the ledc hardware init is being done. 3) If the above doesn’t work, then I suggest you prove your hardware and software first by using the normal Arduino IDE and make sure you’re not introducing some subtle differences by using the hybrid IDF environment. HTH Alex Shepherd
…
On 1/08/2023, at 1:10 AM, murarduino @.***> wrote: open DCC_DEBUG，Connect the four indicator LEDs（ 33, 25, 26, 27） to execute the PROG command, but the indicator does not show anything — Reply to this email directly, view it on GitHub <#74 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5Y53LOJLNCFRP7R5KVIDTXS6VDJANCNFSM6AAAAAA244SR2A. You are receiving this because you are subscribed to this thread.

Yesterday, I used the DCCInspector-EX test to verify if there was a design issue with the hardware connection and the DCC data was read correctly.
Due to space constraints, I chose voltage divider (100KR+33KR) and clamping Schottky for circuit protection. but not sure if an internal pull-up is required. It seems that there is a line in the DCCInspector-EX code that is pinMode(INPUTPIN, INPUT_PULLUP);
The 3rd floor lists the complete code of the test at that time, with the initialization of ledc, and at the same time, in the app_main (), while before calling MOTOR_Ack(), adding LED indicators on the motor output, a series of proofs that the motor can run normally (LED is lit).
I hope it's all just me making some stupid mistakes (but haven't figured out why yet) and not being obsessed with the architecture (Arduino/IDF).

[murarduino]

Today's test results:
1.Dcc.pin(DCC_PIN, 1), output DCC data through WebThrottle-EX, and see DCC instruction through "notifyDccMsg".
2. Dcc.pin(DCC_PIN,0) again, test 1, you can still see the DCC instruction. Indicate whether the internal pull-up is set is independent of whether the signal can be acquired, and indicate that the code can "read" DCC data.
3. Modify the voltage limit of ACK to 10mA through Diagnostics Command to read ACK feedback, and the current detection is still 0mA

4. MOTOR_ACK () can be executed in app_main (), including in a while loop. illustrate that motor operation can be performed.

From the above tests, I believe that the notifyCVAck function was never executed because the ESP_LOGI(LOGTAG_DCC, "notifyCVAck") statement was never seen executed in the ESP32 serial output

[kiwi64ajs]

On 9/08/2023, at 1:56 AM, murarduino ***@***.***> wrote: Today's test results: 1.Dcc.pin(DCC_PIN, 1), output DCC data through WebThrottle-EX, and see DCC instruction through "notifyDccMsg". 2. Dcc.pin(DCC_PIN,0) again, test 1, you can still see the DCC instruction. Indicate whether the internal pull-up is set is independent of whether the signal can be acquired, and indicate that the code can "read" DCC data.

Ok, good the notifyDccMsg() function is showing received packets. Do they look like valid packets - can you hand decode them and make sure they make sense?

3. Modify the voltage limit of ACK to 10mA through Diagnostics Command to read ACK feedback, and the current detection is still 0mA MOTOR_ACK () can be executed in app_main (), including in a while loop. illustrate that motor operation can be performed. From the above tests, I believe that the notifyCVAck function was never executed because the ESP_LOGI(LOGTAG_DCC, "notifyCVAck") statement was never seen executed in the ESP32 serial output

Can you see any DCC Service Mode programming Commands being received via notifyDccMsg() when you’re trying to program the Decoder? Can you send me your current sketch so I can see exactly what you’re doing, and I’ll try and compile and run it here? Alex

[murarduino]

On 9/08/2023, at 1:56 AM, murarduino @.***> wrote: Today's test results: 1.Dcc.pin(DCC_PIN, 1), output DCC data through WebThrottle-EX, and see DCC instruction through "notifyDccMsg". 2. Dcc.pin(DCC_PIN,0) again, test 1, you can still see the DCC instruction. Indicate whether the internal pull-up is set is independent of whether the signal can be acquired, and indicate that the code can "read" DCC data.
Ok, good the notifyDccMsg() function is showing received packets. Do they look like valid packets - can you hand decode them and make sure they make sense?
3. Modify the voltage limit of ACK to 10mA through Diagnostics Command to read ACK feedback, and the current detection is still 0mA MOTOR_ACK () can be executed in app_main (), including in a while loop. illustrate that motor operation can be performed. From the above tests, I believe that the notifyCVAck function was never executed because the ESP_LOGI(LOGTAG_DCC, "notifyCVAck") statement was never seen executed in the ESP32 serial output
Can you see any DCC Service Mode programming Commands being received via notifyDccMsg() when you’re trying to program the Decoder? Can you send me your current sketch so I can see exactly what you’re doing, and I’ll try and compile and run it here? Alex

Hi Alex:

I think the packets output by notifyDccMsg() are correct. For example, the locomotive at address 3 is subjected to direction and speed regulation, and the results are as follows:

I (422) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (933) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (1443) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (1953) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (2463) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (2973) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (3483) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (3993) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (4503) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (5013) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (5523) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (6033) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (6543) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (7053) DCC_MSG: 0x3ffb2b82 03 3f a7 9b |.?..| I (7563) DCC_MSG: 0x3ffb2b82 03 3f 9d a1 |.?..| I (8073) DCC_MSG: 0x3ffb2b82 03 3f 9d a1 |.?..| I (8583) DCC_MSG: 0x3ffb2b82 03 3f 9d a1 |.?..| I (9093) DCC_MSG: 0x3ffb2b82 03 3f 99 a5 |.?..| I (9603) DCC_MSG: 0x3ffb2b82 03 3f 94 a8 |.?..| I (10113) DCC_MSG: 0x3ffb2b82 03 3f 94 a8 |.?..| I (10623) DCC_MSG: 0x3ffb2b82 03 3f 94 a8 |.?..| I (11133) DCC_MSG: 0x3ffb2b82 03 3f 94 a8 |.?..| I (11643) DCC_MSG: 0x3ffb2b82 03 3f 94 a8 |.?..| I (12153) DCC_MSG: 0x3ffb2b82 03 3f 9d a1 |.?..| I (12663) DCC_MSG: 0x3ffb2b82 03 3f 9d a1 |.?..| I (13173) DCC_MSG: 0x3ffb2b82 03 3f 9b a7 |.?..| I (13683) DCC_MSG: 0x3ffb2b82 03 3f 9b a7 |.?..| I (14193) DCC_MSG: 0x3ffb2b82 03 3f 9b a7 |.?..| I (14703) DCC_MSG: 0x3ffb2b82 03 3f a0 9c |.?..| I (15213) DCC_MSG: 0x3ffb2b82 03 3f 8f b3 |.?..| I (15723) DCC_MSG: 0x3ffb2b82 03 3f 8f b3 |.?..| I (16233) DCC_MSG: 0x3ffb2b82 03 3f 8f b3 |.?..| I (16743) DCC_MSG: 0x3ffb2b82 03 3f 0f 33 |.?.3| I (17253) DCC_MSG: 0x3ffb2b82 03 3f 0f 33 |.?.3| I (17763) DCC_MSG: 0x3ffb2b82 03 3f 0f 33 |.?.3| I (18273) DCC_MSG: 0x3ffb2b82 03 3f 0f 33 |.?.3| I (18783) DCC_MSG: 0x3ffb2b82 03 3f 0f 33 |.?.3| I (19293) DCC_MSG: 0x3ffb2b82 03 3f 0f 33 |.?.3| I (19803) DCC_MSG: 0x3ffb2b82 03 3f 00 3c |.?.<| I (20313) DCC_MSG: 0x3ffb2b82 03 3f 00 3c |.?.<| I (20823) DCC_MSG: 0x3ffb2b82 03 3f 00 3c |.?.<| I (21333) DCC_MSG: 0x3ffb2b82 03 3f 00 3c |.?.<| I (21843) DCC_MSG: 0x3ffb2b82 03 3f 00 3c |.?.<| I (22353) DCC_MSG: 0x3ffb2b82 03 3f 00 3c |.?.<| I (22863) DCC_MSG: 0x3ffb2b82 03 3f 00 3c |.?.<| I (23373) DCC_MSG: 0x3ffb2b82 03 3f 00 3c |.?.<| I (23883) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (24393) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (24903) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (25413) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (25923) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (26433) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (26943) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (27453) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (27963) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (28473) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (28983) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (29493) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (30003) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (30513) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (31023) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.| I (31533) DCC_MSG: 0x3ffb2b82 03 3f 34 08 |.?4.|

In the Service Mode, the previous few days are using commands, almost all ff 00 ff, today try to write the command <W 1 5>full output:

I (669473) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (669983) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (670493) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (671003) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (671513) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (672023) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (672533) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (673043) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (673553) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (674063) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (674573) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (675083) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (675593) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (676103) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (676613) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (677123) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (677633) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (678143) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (678653) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (679163) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (679673) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (680183) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (680693) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (681203) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (681713) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (682223) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (682733) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (683243) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (683753) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (684263) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (684773) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (685283) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (685793) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (686303) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (686813) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (687323) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (687833) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (688343) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (688853) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (689363) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (689873) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (690383) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (690893) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (691403) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (691913) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (692423) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (692933) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (693443) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (693953) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (694463) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (694973) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (695483) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (695993) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (696503) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (697013) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (697523) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (698033) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (698543) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (699053) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (699563) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (700073) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (700583) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (701093) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (701603) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (702113) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (702623) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (703133) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (703643) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (704153) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (704663) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (705173) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (705683) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (706193) DCC_MSG: 0x3ffb2b82 ff 00 ff |...| I (706703) DCC_MSG: 0x3ffb2b82 ff 00 ff |...|

All tests are run on the programming track.
I packaged the whole environment (including Arduino and NmraDCC components, some code I adjusted), about 60MB, I sent to your Gmail mailbox, please check.

BTW:Besides GitHub, how can I contact you in time for advice?

[murarduino]

I switched to PlatformIO+Arduino architecture and had the same problem. I suspected that CV was not written to EEPROM correctly, so I added a check_CV function to verify. Results:
CV1: 255
CV17: 3
CV18: 255
CV29: 255

I don't understand why this is happening.

main.zip

[kiwi64ajs]

When a CV = 255 that usually means it's the default value after an EEPROM erasure, which is probably why you’re seeing the 255 values. Your sketch hasn’t initialised any of the CVs in the Emulated EEPROM in the ESP32. So you need to add some logic to force the Sketch to actually set the CVs to the values in the FactoryDefaultCVs array, like this: https://github.com/mrrwa/NmraDcc/blob/master/examples/NmraDccMultiFunctionMotorDecoder/NmraDccMultiFunctionMotorDecoder.ino#L237 https://github.com/mrrwa/NmraDcc/blob/master/examples/NmraDccMultiFunctionMotorDecoder/NmraDccMultiFunctionMotorDecoder.ino#L320 However, as the ESP32 EEPROM is emulated in FLASH, you will probably overwrite them each time you update the Sketch. HTH Alex

…

On 15/08/2023, at 11:59 PM, murarduino ***@***.***> wrote: I switched to PlatformIO+Arduino architecture and had the same problem. I suspected that CV was not written to EEPROM correctly, so I added a check_CV function to verify. Results: CV1: 255 CV17: 3 CV18: 255 CV29: 255 I don't understand why this is happening. main.zip <https://github.com/mrrwa/NmraDcc/files/12343813/main.zip> — Reply to this email directly, view it on GitHub <#74 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5Y53L4Z6HYP7BBKUKA54LXVNQC7ANCNFSM6AAAAAA244SR2A>. You are receiving this because you commented.

[murarduino]

It is the problem that I call the wrong object when I write the check_CV function. The original code:

Serial.printf("CV%d: %d\n", FactoryDefaultCVs[i].CV, Dcc.getCV(i));

Dcc.getCV should call CVKey to modify the code:
uint16_t CV_key =FactoryDefaultCVs[i].CV; Serial.printf("id:%d CV%d: %d\n",i, CV_key, Dcc.getCV(CV_key));

The value is correct because, when I wrote the CV, I added serial validation:
if (FactoryDefaultCVIndex && Dcc.isSetCVReady()) { FactoryDefaultCVIndex--;// Decrement first as initially it is the size of the array Serial.printf("id:%d CV%d: %d\n",FactoryDefaultCVIndex, FactoryDefaultCVs[FactoryDefaultCVIndex].CV, FactoryDefaultCVs[FactoryDefaultCVIndex].Value); Dcc.setCV(FactoryDefaultCVs[FactoryDefaultCVIndex].CV, FactoryDefaultCVs[FactoryDefaultCVIndex].Value); }

Serial output:
id:3 CV29: 2 id:2 CV18: 3 id:1 CV17: 192 id:0 CV1: 3 id:0 CV1: 3 id:1 CV17: 192 id:2 CV18: 3 id:3 CV29: 2
The code can be written to EEPROM normally, but further investigation of ACK problem is needed.
As for the problem of re-writing the EEPROM every time you restart it, I think it can be avoided by adding a notifyIsSetCVReady external function, such as whether CV8 has been modified.

[murarduino]

The problem lies in Dcc processing. Add serial output in NmraDCC.cpp to determine the problem. Test as follows:

1. In processServiceModeOperation(), first add serial output, no display.
2. In execDccProcessor(), first add serial output, there is display.
3. After the three main decision statements (1288, 1305 and 1323) in execDccProcessor(), add serial output, the result is only 1323(else) statement, print DccProcState.inServiceMode at this location, the result is 0.
   The entire code should be running empty, there is no positive condition to enter 1305, so the processServiceMode() cannot be executed.