Serial Port problem in 6.35

[DimitriosGk]

Hello,

We seem to have an issue with the serial monitor of the last release of your sw. The software gets uploaded succesfully (checked it by using the BLINK_LED also), but when i open the serial monitor nothing seems to be going on. At the same time, the PORT loses connection repeatedly, tested in more than 2 computers.

I tried unistalling everything and installing again but the problem persists (Including due libs & drivers etc.). I used the old sw (for versions until GEVCU 4) and it works fine with the serial, but in this one it does not recognize the inputs (I connected a potensiometer and checked that it works with a multimeter also-the input never showed up on the serial monitor), probably because of some changes in the pinout of the newer versions of GEVCU.

Do you have any solution in mind for that problem?

Thank you,

[collin80]

I assume you're compiling it yourself? If so, try the binary updater from EVTV: http://media3.ev-tv.me/GEVCUupdate6.zip and see if that works. Also, you might try the "DEV" branch of GEVCU6. I have been using that branch in a car so I know it works. I'm don't think I've used the master branch recently. I thought it was stable but perhaps there's an issue with newer libraries or Arduino version.

On Sat, Jan 19, 2019 at 6:33 AM Dimitrios Gkotsoulias < notifications@github.com> wrote:

Hello,

We seem to have an issue with the serial monitor of the last release of your sw. The software gets uploaded succesfully (checked it by using the BLINK_LED also), but when i open the serial monitor nothing seems to be going on. At the same time, the PORT loses connection repeatedly, tested in more than 2 computers.

I tried unistalling everything and installing again but the problem persists (Including due libs & drivers etc.). I used the old sw (for versions until GEVCU 4) and it works fine with the serial, but in this one it does not recognize the inputs (I connected a potensiometer and checked that it works with a multimeter also-the input never showed up on the serial monitor), probably because of some changes in the pinout of the newer versions of GEVCU.

Do you have any solution in mind for that problem?

Thank you,

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/collin80/GEVCU6/issues/8, or mute the thread https://github.com/notifications/unsubscribe-auth/ACC7ZW2MUH_ffyQTq9Wn9ncUsKPLmzddks5vEwJ6gaJpZM4aJGHi .

[DimitriosGk]

Hi,

Thanks for the answer. I tried the .bin files but no luck either. Even if the .bin of a previous compile works, we need the source code to d changes etc. I will try the DEV branch. One more note: I have tried to print using serialusb.println() in the serial monitor and it works properly. Then I try to add modules within my .ino (adding the relevant cpp and .h files) and until some point i can see the message on the serial monitor as well as the led blinking, as i have commanded (for check) in the loop(){}. After adding wire.begin... and memchace instructions it fails to get in the loop and just projects repeated warnings and info messages to the console regarding the values of the config file. It never prints the menu nor the heartbeat either. What is the last stable arduino version you compiled and worked with? Should I work with the updated libraries or with the ones that i can find in your git repository?

[collin80]

The DEV branch is here on github: https://github.com/collin80/GEVCU6/tree/DEV

Or, if you're using command line GIT you can do this: "git checkout DEV"

But, the binary EVTV has really ought to work - at least for testing that the hardware is functional. So, it seems like something is going on. In the setup function of GEVCU6.ino, near the top, you will find delay(5000); commented out. Uncomment that and recompile. Now it waits 5 seconds before it does much of anything.

Further, for even better debugging. Add this line directly under the delay: Logger::setLoglevel((Logger::LogLevel)0);

Also, comment out the Logger::setLoglevel call around 20 to 25 lines further down. Now the whole system is stuck in the maximum debugging level and will output all sorts of debugging text. If you send me the output text I'll have a good idea of where things are going wrong.

On Sun, Jan 20, 2019 at 9:37 AM Dimitrios Gkotsoulias < notifications@github.com> wrote:

Hi,

Thanks for the answer. I tried the .bin files but no luck either. Even if the .bin of a previous compile works, we need the source code to d changes etc. I will try the DEV branch. One more note: I have tried to print using serialusb.println() in the serial monitor and it works properly. Then I try to add modules within my .ino (adding the relevant cpp and .h files) and until some point i can see the message on the serial monitor as well as the led blinking, as i have commanded (for check) in the loop(){}. After adding wire.begin... and memchace instructions it fails to get in the loop and just projects repeated warnings and info messages to the console regarding the values of the config file. It never prints the menu nor the heartbeat either. What is the last stable arduino version you compiled and worked with? Should I work with the updated libraries or with the ones that i can find in your git repository?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/collin80/GEVCU6/issues/8#issuecomment-455871641, or mute the thread https://github.com/notifications/unsubscribe-auth/ACC7ZSDnaRZqftNPL3vrXiKvqS5ywkZDks5vFH8bgaJpZM4aJGHi .

[DimitriosGk]

I followed your instructions, I attach a file with the console output text: debug.zip

I have tried also using all the old libraries found in git, not updated. Again i had the same results, any version of GEVCU6 seems to work. Only the older one works. I thought about changing the pin assignment to the old one but I have not yet checked if it works properly.

Let me know what you think. I will keep trying stuff, tomorrow Ill be at work so I will try again with another computer if possible.

[collin80]

Sorry I apparently wasn't clear what I was asking. I hoped you might show me what the serial console says when it boots up. In there should be a lot of debugging messages that will help to figure out why it doesn't work.

On Sun, Jan 20, 2019 at 2:24 PM Dimitrios Gkotsoulias notifications@github.com wrote:

I followed your instructions, I attach a file with the console output text: debug.zip

I have tried also using all the old libraries found in git, not updated. Again i had the same results, any version of GEVCU6 seems to work. Only the older one works. I thought about changing the pin assignment to the old one but I have not yet checked if it works properly.

Let me know what you think. I will keep trying stuff, tomorrow Ill be at work so I will try again with another computer if possible.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[DimitriosGk]

The only thing i get on the serial console is this message continuously:

19977 - WARNING: DMC5 - Invalid checksum, using hard coded config values 19982 - DEBUG: New checksum: D 19985 - INFO: MaxTorque: 0 MaxRPM: 2 19986 - WARNING: DMC5 - Invalid checksum, using hard coded config values 19991 - DEBUG: New checksum: 65 19993 - INFO: MaxTorque: 0 MaxRPM: 3 19995 - WARNING: DMC5 - Invalid checksum, using hard coded config values 19999 - DEBUG: New checksum: 35 20002 - INFO: MaxTorque: 0 MaxRPM: 3 20003 - WARNING: DMC5 - Invalid checksum, using hard coded config values 20008 - DEBUG: New checksum: F5

After that (for around 5 s) the serial port stops showing anything. It actually freezes. What are your versions of IDE / DUE driver / libs/ software?

[DimitriosGk]

Same if i do almost the same changes on the DEV branch. I get repeatedly: 44854 - WARNING: DMC5 - Invalid checksum, using hard coded config values 44858 - DEBUG: New checksum: 5D 44873 - INFO: Checksum matches Value: 0x5D 44875 - INFO: Valid checksum, using stored config values 44877 - INFO: MaxTorque: 32 MaxRPM: 1873 44878 - WARNING: DMC5 - Invalid checksum, using hard coded config values 44883 - DEBUG: New checksum: 95 44897 - INFO: Checksum matches Value: 0x95 44899 - INFO: Valid checksum, using stored config values 44901 - INFO: MaxTorque: 8199 MaxRPM: 59820

So the problem is that it never reaches to the point of loop(). Something is going wrong in setup, after lines digitalWrite(BLINK_LED, LOW);. I set the led HIGH to see if i get there and it actually reaches up to that point. Then it looks like it is reseting, the led goes LOW and we hear the sound of unpluging the board. This happens continouusly with something like 10 seconds between each time. The LED goes HIGH and then again LOW with unpluging sound. Is there any reason that the device would be reseting?

[collin80]

Weird... I suppose it might have something to do with the DMC5 code. You see, I've never once enabled that device personally. Someone else wrote it and used it and it was for the GEVCU4 code. To my knowledge no one has tested it in GEVCU6. It's possible that some changes broke the code and since no one needed that device to work it sat broken since. I'll have to give it a try and see if using that device breaks for me too. Currently there isn't any good way to quit using a device if it breaks things before you can get to the serial console. You can, of course, comment out that device so it doesn't get added to the system but that doesn't do you a lot of good.

I do have to wonder, did it mess up before you enabled the DMC5 device? I really do wonder if the whole problem is in that code.

On Mon, Jan 21, 2019 at 8:40 AM Dimitrios Gkotsoulias < notifications@github.com> wrote:

Same if i do almost the same changes on the DEV branch. I get repeatedly: 44854 - WARNING: DMC5 - Invalid checksum, using hard coded config values 44858 - DEBUG: New checksum: 5D 44873 - INFO: Checksum matches Value: 0x5D 44875 - INFO: Valid checksum, using stored config values 44877 - INFO: MaxTorque: 32 MaxRPM: 1873 44878 - WARNING: DMC5 - Invalid checksum, using hard coded config values 44883 - DEBUG: New checksum: 95 44897 - INFO: Checksum matches Value: 0x95 44899 - INFO: Valid checksum, using stored config values 44901 - INFO: MaxTorque: 8199 MaxRPM: 59820

So the problem is that it never reaches to the point of loop(). Something is going wrong in setup, after lines digitalWrite(BLINK_LED, LOW);. I set the led HIGH to see if i get there and it actually reaches up to that point. Then it looks like it is reseting, the led goes LOW and we hear the sound of unpluging the board. This happens continouusly with somethong like 10 seconds between its time. The LED goes HIGH and then again LOW with unpluging sound. Is there any reason that the device would be reseting?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/collin80/GEVCU6/issues/8#issuecomment-456077821, or mute the thread https://github.com/notifications/unsubscribe-auth/ACC7ZWu7Yq1m85sQ07n2ZkqskYpOzRHTks5vFcNpgaJpZM4aJGHi .

[collin80]

It seems that indeed the code to support the DMC5 was broken at some point and it was never used so no one ever noticed. If you comment out line 354 which is saveConfiguration(); and found directly under config->enableOscillationLimiter = false; then it should work. It looks like someone started to support loading settings from EEPROM but never got 100% of the way there and then it was left as a mess. For now just comment out the call and maybe even everything within the saveConfiguation function just to be safe. I'll try to fix it all up soon so that it actually supports saving the settings to EEPROM like it should. In the meantime everything will be hard coded as far as settings go.

On Mon, Jan 21, 2019 at 8:39 PM Collin Kidder collink@kkmfg.com wrote:

Weird... I suppose it might have something to do with the DMC5 code. You see, I've never once enabled that device personally. Someone else wrote it and used it and it was for the GEVCU4 code. To my knowledge no one has tested it in GEVCU6. It's possible that some changes broke the code and since no one needed that device to work it sat broken since. I'll have to give it a try and see if using that device breaks for me too. Currently there isn't any good way to quit using a device if it breaks things before you can get to the serial console. You can, of course, comment out that device so it doesn't get added to the system but that doesn't do you a lot of good.

I do have to wonder, did it mess up before you enabled the DMC5 device? I really do wonder if the whole problem is in that code.

On Mon, Jan 21, 2019 at 8:40 AM Dimitrios Gkotsoulias < notifications@github.com> wrote:

Same if i do almost the same changes on the DEV branch. I get repeatedly: 44854 - WARNING: DMC5 - Invalid checksum, using hard coded config values 44858 - DEBUG: New checksum: 5D 44873 - INFO: Checksum matches Value: 0x5D 44875 - INFO: Valid checksum, using stored config values 44877 - INFO: MaxTorque: 32 MaxRPM: 1873 44878 - WARNING: DMC5 - Invalid checksum, using hard coded config values 44883 - DEBUG: New checksum: 95 44897 - INFO: Checksum matches Value: 0x95 44899 - INFO: Valid checksum, using stored config values 44901 - INFO: MaxTorque: 8199 MaxRPM: 59820

So the problem is that it never reaches to the point of loop(). Something is going wrong in setup, after lines digitalWrite(BLINK_LED, LOW);. I set the led HIGH to see if i get there and it actually reaches up to that point. Then it looks like it is reseting, the led goes LOW and we hear the sound of unpluging the board. This happens continouusly with somethong like 10 seconds between its time. The LED goes HIGH and then again LOW with unpluging sound. Is there any reason that the device would be reseting?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/collin80/GEVCU6/issues/8#issuecomment-456077821, or mute the thread https://github.com/notifications/unsubscribe-auth/ACC7ZWu7Yq1m85sQ07n2ZkqskYpOzRHTks5vFcNpgaJpZM4aJGHi .

[DimitriosGk]

Hey Collin,

seems to work without using the saveConfiguration() function! Issue can be resolved.

[chadman98126]

perhaps it's worthwhile to check these changes into the Dev and/or Main branches? (to avoid this issue until the save to EEPROM call(s) are fixed)