Serial Communication is not functioning
Closed this issue · 51 comments
It appears that serial communication is not functioning, I can connect to the port but all I get is Frame Err! in response to anything.
Not sure if this is relative to the no step issue, but I'm unable to read or write and PID Current or Micro step parameters for example by Serial.
Just thought I would Post this for you.
I'll look into the stepping issue first, then the serial configuration. I'm going to make a project, so that way you can see what I'm currently working on
Sounds good. That way i don't have to report what you're already aware of for your own sanity lol
Should be all set up now
Just to add to this, When the Serial is working (shipped firmware) When you have a ttl adapter connected and on boot (after calibration) Below is the serial output in a terminal. And of course changing PID and what not works.
rxbuf[0]:0x31
rxbuf[1]:0x32
rxbuf[2]:0x33
rxbuf[3]:0x34
rxbuf[4]:0x35
rxbuf[5]:0x36
rxbuf[6]:0x37
rxbuf[7]:0x38
CAN1 Transport OK!
@GhostlyCrowd Just do you know, I'm going to be finishing the parser soon, so the original serial issue you were having should be non-existent. I decided to completely redo the code based on the Arduino framework. This made more libraries accessible and the code is overall easier to understand and navigate. The stepping routine is the other thing I've been working on. I'm hoping to have the re-write done within the next couple of weeks. I still need to finish up some of the display menus, make sure that the display works, add saving parameters, implement a new calibration style, implement the new encoder library, add a manual tuning utility, and bring back the CAN bus (don't know how much this will actually be used). What are your thoughts on the current state? Are you still interested?
@GhostlyCrowd Just do you know, I'm going to be finishing the parser soon, so the original serial issue you were having should be non-existent. I decided to completely redo the code based on the Arduino framework. This made more libraries accessible and the code is overall easier to understand and navigate. The stepping routine is the other thing I've been working on. I'm hoping to have the re-write done within the next couple of weeks. I still need to finish up some of the display menus, make sure that the display works, add saving parameters, implement a new calibration style, implement the new encoder library, add a manual tuning utility, and bring back the CAN bus (don't know how much this will actually be used). What are your thoughts on the current state? Are you still interested?
I am indeed still interested and have been following your project. I was just out of town on business this past week or i would have replied sooner.
Great to hear! I know it's taking a while, but the results should be far better than the original firmware. I've already implemented CAN communication, so in future Marlin could interface directly with the board to set all of the parameters.
Great to hear! I know it's taking a while, but the results should be far better than the original firmware. I've already implemented CAN communication, so in future Marlin could interface directly with the board to set all of the parameters.
This is excellent I'm excited, I usually pull your changes and flash them each time just to see what manner of working its in.
How has it been going? I really haven't been testing the builds other than that they compile correctly. Is the LCD working? The motor moving at all? I just fixed all of the motor stuff and it should just be debugging on the motor
How has it been going? I really haven't been testing the builds other than that they compile correctly. Is the LCD working? The motor moving at all? I just fixed all of the motor stuff and it should just be debugging on the motor
just compiled, nothing appears to be working yet. What do you think should be working so far? I was assuming that until the rewrite is finished this is normal.
Were you able to test the Serial communications? As for the OLED, I think that they used non standard pins (so it’s really annoying to work with) The motor not moving… well that’s another issue. I’ll have to grab the boards off my printer and do some testing this week(end).
Make sure that you add a < in front of the message and a > afterward. Then again, I didn’t write any feedback yet… I’ll have to add some feedback prints
There, now there’s feedback and the serial should be parsed on a regular interval
Ok, I cant get it to compile, getting the same error that PlatformIO CI is getting
"collect2: error: ld returned 1 exit status
looks like ld doesnt like the flashWrite function you added. I'm no coder though.
Not sure about those depends errors, I fixed those previously. I'm currently working on fixing the issue with the flash functions causing the code not to compile
Not sure about those depends errors, I fixed those previously. I'm currently working on fixing the issue with the flash functions causing the code not to compile
Im going to do a fresh rebase
Finally figured it out. Should be good to test now. Sorry for the delay, it took me a little while to figure out what had happened
Finally figured it out. Should be good to test now. Sorry for the delay, it took me a little while to figure out what had happened
No worries i got it flashed now, but its still not doing anything. OLED is not working, I cannot get any serial commands to run nor do i get any serial feedback.
I verified my serial is working with the Stock firmware.
Are the dips still the same as before The documentation was backwards for me as you know dip1 was calibration 2 was close loop.
Serial baud still 38400?
Looks like were getting very close though.
Serial is now at 115200. I upped it for now, I want to see how it goes. Take a look at the README. I also built in a way to set the dips as reversed, such as they are in your case. I haven't got to implement it in gcode yet
Serial is now at 115200. I upped it for now, I want to see how it goes. Take a look at the README. I also built in a way to set the dips as reversed, such as they are in your case. I haven't got to implement it in gcode yet
Thanks for all theh ard work, 115200 still nothing, I wil continue to fiddle with it and follow your commits.
If there is anything you'd like me to test let me know. Maybe we have the pins wrong? i wish BTT documented better
Yeah, I think it’s a pin issue. Either that, or the display is holding everything up. Like I said, I’ll get my boards off of my printer and try to get at least some of the basic stuff working. I appreciate your help and feedback, thanks!
Alright pulled todays changes still no serial for me. tried Putty and BTT's serial terminal, i never get a reply. One thing to note is i cannot get any serial reply from the factory firmware either until calibration is run. So this may be an issue as well.
Is there any output at all? If there's nothing printing, then it's a pin/serial config issue. If it is printing, then it's a parser issue. As for no reply until calibration, I already added the serial prints/reads to both the calibrated and not calibrated loops
Is there any output at all? If there's nothing printing, then it's a pin/serial config issue. If it is printing, then it's a parser issue. As for no reply until calibration, I already added the serial prints/reads to both the calibrated and not calibrated loops
No output at all, no reply to anything. So seems to be pins
Darn. I'll try to fix it this weekend
Darn. I'll try to fix it this weekend
no worries man, thanks for all the effort
For what its worth i believe UART2 PA2 = TX and PA3 = RX is the mcu default but who knows what they decided on.
Yeah, I've been working on trying to run any code at all, but the LED won't blink (probably issue with programming or incorrect pins). I'm going to try just sending data over serial. So far, the only thing I know is that the board isn't functioning. I'll try to see if I can find the solution tomorrow. If not, I might have to wait for a forum post
Yeah, I've been working on trying to run any code at all, but the LED won't blink (probably issue with programming or incorrect pins). I'm going to try just sending data over serial. So far, the only thing I know is that the board isn't functioning. I'll try to see if I can find the solution tomorrow. If not, I might have to wait for a forum post
I'll keep an eye out good luck
@GhostlyCrowd I found the problem, it was due to an encoder setup line. The menu system is almost 100% functional (there's a minor issue where it won't open the second level menu if you've already opened and closed it a couple times). Would you mind testing the serial? The baud should be 115200 and all messages (see the g-code reference) should have greater and less than signs like this:
< M500 >
Certainly, pulling it in a few minutes just letting my dog out
Serial workingSerial workingSerial workingSerial workingSerial workingSerial workingSerial workingSerial workingSerial workingSerial workingSerial workingSerial workingSerial workingSerial workingSerial workingSerial workingSerial workingSerial working
👍
Oled is working led's flashing and working, reeset button working. asking to calibrate thats as far as it gets for me though
<M307> No command specifiedSerial Working
Is it still dip 1 on to calibrate? like the stock firmware
Terrific! That's exactly what it should be printing. Do any of the commands work? I'll look into the M307 error, that shouldn't need any parameters. As for the calibration, it hasn't been written yet, so that'll be next on the list after fixing the serial issues. I'm going to remove the "Serial working" message, it's unnecessary now. I'm glad that the large portion of the code that I've wrote is working though.
@GhostlyCrowd commit dd22ed3 should fix your issue. I also fixed the menu issue (due to not factoring in that the menu moves past the length of the menu).
c_cpp_properties.json includes some missing paths, looks like /src/lib/fastDigitalWrite and /include weren't in the commit?
c_cpp_properties.json includes some missing paths, looks like /src/lib/fastDigitalWrite and /include weren't in the commit?
All fixed in 869751f. Please create a new issue next time, it'll make the organization much easier for me.
@CAP1Sup Thanks. Fair, you got it.
@GhostlyCrowd which repo/branch are you getting your stock firmware from? BTTs repos are a bit of a convoluted mess...
@lav8org I have a copy of the production firmware in the precompiled folder. That is the firmware that shipped with my board. I extracted it off of the board so I know it works properly. I would advise recalibrating after you flash it. You can flash it using ST Link
@GhostlyCrowd commit dd22ed3 should fix your issue. I also fixed the menu issue (due to not factoring in that the menu moves past the length of the menu).
I'll have to give ti a go monday left my gear in my office and im not in until then. No commands at all worked. all returned the same error.
No problem, whenever you get the chance. I'll look into the issue with not receiving commands correctly tomorrow
@GhostlyCrowd commit dd22ed3 should fix your issue. I also fixed the menu issue (due to not factoring in that the menu moves past the length of the menu).
Just gave this a flash same situation for me.
Oled is working led's flashing and working, reset button working. Asking to calibrate that's as far as it gets for me though, won't calibrate button presses don't get me to menus. "Close loop Mode Use theT select Keyd! Ito Calibrate" Couple of typos in the oled code but that's semantics.
No command specified
Getting close! I suppose the serial issues are solved so technically this issue is closeable but it's a good spot to keep the chat open.
Glad the OLED's working. The calibration isn't written yet, I made a note on the OLED panel. I also fixed your issue with the OLED display, I forgot to clear the display before writing new data to it. The No command specified error is quite annoying, I'll have a crack at it this weekend when I take a look over the encoder code. Let me know if there's any other issues with OLED typos. And yes, the serial issue is fixed but I'd like to keep this for now. It's good to know how end users are doing with the boards and have some positive encouragement that someone besides myself is going to find this useful. So like I said, this weekend I should be able to at least get the a chance to fix the serial and stepper issues still remaining.
The changes can be seen in d32f8af
Glad the OLED's working. The calibration isn't written yet, I made a note on the OLED panel. I also fixed your issue with the OLED display, I forgot to clear the display before writing new data to it. The No command specified error is quite annoying, I'll have a crack at it this weekend when I take a look over the encoder code. Let me know if there's any other issues with OLED typos. And yes, the serial issue is fixed but I'd like to keep this for now. It's good to know how end users are doing with the boards and have some positive encouragement that someone besides myself is going to find this useful. So like I said, this weekend I should be able to at least get the a chance to fix the serial and stepper issues still remaining.
The changes can be seen in d32f8af
Excellent ill keep an eye out and test as needed.
I tried your version, compile and upload work perfect. But I am new to STM and uses VS Code on Linux with the STLink V2 adapter and do not know how to send serial commands to the board.
Do I use the STLink adapter the same way as to update the firmware for serial connect too?
I tried your version, compile and upload work perfect. But I am new to STM and uses VS Code on Linux with the STLink V2 adapter and do not know how to send serial commands to the board.
Do I use the STLink adapter the same way as to update the firmware for serial connect too?
I think that you have to connect a Serial adapter to the serial pins. The JTAG interface is one sided to my knowledge
I tried your version, compile and upload work perfect. But I am new to STM and uses VS Code on Linux with the STLink V2 adapter and do not know how to send serial commands to the board.
Do I use the STLink adapter the same way as to update the firmware for serial connect too?
If there is a serial client in VScode, PlatformIO would be providing it, so that would be where to search. But there are many mature standalone apps; on the gui side I've been very happy with CuteCom, although it is the first and only one I've used
@lav8org I have a copy of the production firmware in the precompiled folder. That is the firmware that shipped with my board. I extracted it off of the board so I know it works properly. I would advise recalibrating after you flash it. You can flash it using ST Link
Thank you!! I had in mind to image the stock FW when I ordered them, but after the long wait for their arrival I feverishly went full Leroy Jenkins and immediately flashed the lot with Intellistep, still unaware that it's a WIP.
@lav8org I have a copy of the production firmware in the precompiled folder. That is the firmware that shipped with my board. I extracted it off of the board so I know it works properly. I would advise recalibrating after you flash it. You can flash it using ST Link
Thank you!! I had in mind to image the stock FW when I ordered them, but after the long wait for their arrival I feverishly went full Leroy Jenkins and immediately flashed the lot with Intellistep, still unaware that it's a WIP.
I definitely have done the same. I'll be finishing up Intellistep soon, looking forward to being able to use them on my own machine as well as helping you guys get better quality.
Once I finish the coding, I'll fix the README so that it has instructions about restoring, flashing, etc.
Pulled the changes today. Still no stepper movement althought on power up you can feel the stepper take a single step. no calibration movement but states its "starting soon" , menus seem to work.
Just for my sanity check, Dip 1 is now dip 1 and Dip 4 is dip 4 in the sens of logic that Dip 4 is now on to calibrate and Dip 3 is closed loop where as stock firmware Dip1 was calibrate and Dip 2 closed loop?
Serial is still throwing back <M607> No command specified <M307> No command specified <M308> No command specified
Pulled the changes today. Still no stepper movement althought on power up you can feel the stepper take a single step. no calibration movement but states its "starting soon" , menus seem to work.
Just for my sanity check, Dip 1 is now dip 1 and Dip 4 is dip 4 in the sens of logic that Dip 4 is now on to calibrate and Dip 3 is closed loop where as stock firmware Dip1 was calibrate and Dip 2 closed loop?
Serial is still throwing back `
No command specified
No command specified
No command specified`
Thanks for the feedback. The motor only enables right now, it doesn't have the encoder so it can't identify its current position and therefore can't understand what the coils should be at. I'll be fixing the encoder very soon, it's on the top of my list. The dips can be set to be normal or reversed. The reverse mode only corrects the number so that it is read correctly. It doesn't invert the logic as well. I think that the Serial is being read wrong (not a parser issue) but I'll be doing some more testing soon. I'm hoping to have the motor at least open loop and the Serial fixed by the end of the Easter break. Thanks again for giving me feedback, it helps a lot.
@GhostlyCrowd Yup, I was wrong, it was a parser issue. In case you were interested about the issue, the parser has a function to read the value after a letter in a line of gcode. Unfortunately, it was including the letter, meaning it failed to convert the number to a number because it had an extra letter with it. An example would be a command. The parser function was only supposed to return 500, but instead it was returning M500, which couldn't be read as a number. Anyway, the serial should be fixed and you can now use it whenever you like. I'm going to keep the < and > for now, but maybe I'll figure out how to remove those at a later date. Anyway, that concludes this thread. Please post all of you comments on performance under the discussions tab. That way, it will be tidier.