Closed Roxy-3D closed 6 years ago
alex-gh
commented
7 years ago According to the schematics, the SWD/JTAG pins of Re-ARM are not broken out. You would need some fine soldering skills to attach a debug connector to it.
Then you might be able to use something like a Segger J-Link. Or maybe use a FT2232H based breakout board to DIY an SWD adapter.
Roxy-3D
commented
7 years ago This is depressing...
Grogyan
commented
7 years ago The Re-Arm has pins for a UART port not soldered, I thought this was the JTAG port. I could be wrong
Bob-the-Kuhn
commented
7 years ago The only hardware bedbug pins that are connected to anything is the trace port. All the others are on pins 1-5 which are not connected.
{2,4}, // DIO9 RAMPS_D9_PIN
{2,5}, // DIO10 RAMPS_D10_PIN
{2,3}, // DIO46 Z_STEP_PIN
{2,6}, // DIO59 LCD_A0
{2,2}, // DIO60 Y_STEP_PIN
I haven't found anything yet that hooks up to this port but I'm still looking.
ekozan
commented
7 years ago https://www.thingiverse.com/thing:801279 <- problems solved ? :D
kfazz
commented
7 years ago Very few interrupt capable pins available either, most are routed to outputs. The pin layout is weird. why leave ramps pins open and then add extra headers? Teensy 3.5/2.6 also don't have JTAG/SWD available, the pins are there, but the programming chip prevents its use. Due uses some ROM'd bootloader and a fine pitch JTAG header, but should at least be debugable. Are there any 32 bit boards with proper debug support?
Roxy-3D
commented
7 years ago Are there any 32 bit boards with proper debug support?
Well... In the big picture there are a couple of good options. One idea is we ask Panucatt devices to include a debug header on any new boards they order. I suspect they would have to submit a new board file to who ever makes the boards, but it would not be that hard for them to do it...
In the mean time... If somebody can solder the wires to a connector and do a close up picture of the work... I'll break out a magnifying glass and heat up the old Weller soldering iron I have.
Bob-the-Kuhn
commented
7 years ago I used to work with a few people that could dead bug something to those pins. You need the equipment, lots of practice and steady hands in order to do that kind of work.
Your best bet is to find someone that works at a contract manufacturer and see if they'll do you a favor.
teemuatlut
commented
7 years ago Teensy 3.5/2.6 also don't have JTAG/SWD available, the pins are there, but the programming chip prevents its use
Hopefully that will change during this year.
bobc
commented
7 years ago We had this exact same conversation only a few months ago :)
https://flic.kr/p/Ezb1xabobc
commented
7 years ago I created an annotated pic showing signals in Nov2016, apparently I didn't upload then.
Re-ARM is a little more tricky because the CPU is under the RAMPS, but the same principle would work. The solder joints on the CPU are quite fragile, you have to be careful to avoid moving the wires. I glued the connector onto the CPU.
Roxy-3D
commented
7 years ago And of great interest is the fact only two of those wires are actually connected to the CPU. Those CPU pins do not appear to be connected to anything on the schematic. So, applying some heat and using the point of an X-Acto knife to lift them up would make them much easier to solder wires onto them. But even without doing that... It is just two wires to the CPU (at least on the Smoothieboard). I think I could do that without destroying the board.
And it looks like there would be room to glue the dead bug connector onto the same connector that D0 to D7 come out on the Atmega-2560 board. Or.... It might make sense to dead bug the connector onto the bottom of the board.
If somebody here with a Re-ARM board can get that to work, some of us will copy the work!!!!
apballard
commented
7 years ago If I may make a suggestion, something that's made life easier for me when doing this?
I've found it easier by using a single strand of enameled copper wire. Use a sharp knife to scrape enamel off of last 1mm, tin it, tin the pins and it's literally holding the wire on the pin and then just quickly touching the iron onto it.
A pointed bit for the iron is normally useful.
The single strand makes it a lot easier and the enamel will prevent shorts. Start from inside and work out.
Not much can go wrong.
kfazz
commented
7 years ago That was my plan, and since I've fried my first ReArm board to the point where it no longer enumerates as a USB device (plugged in a stepper one pin off, steppers fried, board fried), I have nothing to lose. If I can find my last roll of enameled wire. My second ReArm is in the mail.
Roxy-3D
commented
7 years ago If one of you gets a debugger working on it... Please post pictures!
alex-gh
commented
7 years ago It is just two wires to the CPU (at least on the Smoothieboard). I think I could do that without destroying the board.
You probably want 3 wires (pin 1,3,5). It is useful to have access to the SWO pin for trace and debugging output.
Roxy-3D
commented
7 years ago You probably want 3 wires (pin 1,3,5). It is useful to have access to the SWO pin for trace and debugging output.
OK! And with either the single strand of enameled wire or by lifting the pin and soldering to that... I still think I can do 3 wires. If you get it working, there are people here that will copy your setup.
Bob-the-Kuhn
commented
7 years ago I have a 95% functional J-Link debugger / PlatformIO / Re-ARM setup. I'm pretty sure I have a software problem (or a user problem) keeping me from full functionality.
Attached are pictures of what I did and the process I used to modify the Re-ARM card. Re-ARM debug modifications.zip
The wiring isn't pretty but it is functional.
Right now with PlatformIO I can single step through source code and monitor variables. I can't set breakpoints or display memory yet. PlatformIO is complaining about not linking to the GDB server. Hopefully I'll have full functionality once I figure that out.
Included in the ZIP is the platformio.ini file I'm using along with the debug_extra_script.py file that was in the example I started from.
The debug environment in the platformio.ini file is arbitrarily named jlink_debug_and_upload. To actually debug:
Roxy-3D
commented
7 years ago Wow Bob!!!! That is great news!!!! If you can single step, for sure you will be able to set break points and display memory soon!!! I'm going to copy your work!!!
Bob-the-Kuhn
commented
7 years ago I finally figured out how to set breakpoints. It's done via a GDB command shell.
This is my first run in with the Gnu Debugger. A CLI tool with a 700 page manual can be intimidating. There's probably only a handful of commands that'll be used 99% of the time.
There are some GUI elements that PlatformIO provides. Except for the single stepping the basic process is to issue commands via the CLI and review the results in the GUI.
PlatformIO is fragile. I've had to put my Python 3.6 behind Python 2.7 in the path to eliminate some of the problems. Twice today I've had to uninstall Atom, delete all the Atom & PlatformIO directories I could find and then re-install to eliminate some compile/run issues that popped up & wouldn't go away. Some of the errors were caused by PlatformIO not installing all the GCC files it needed. But then on the next install they were all there. Strange stuff.
Roxy-3D
commented
7 years ago I finally figured out how to set breakpoints. It's done via a GDB command shell. This is my first run in with the Gnu Debugger. A CLI tool with a 700 page manual can be intimidating. There's probably only a handful of commands that'll be used 99% of the time.
Bob, are you running GDB on Windows ? I hope so... But if not I'll probably load an old laptop with Linux so I can copy your setup.
There are some GUI elements that PlatformIO provides. Except for the single stepping the basic process is to issue commands via the CLI and review the results in the GUI.
It would be very helpful if you could add a page to your document up above describing how to setup the software environment. And then how to set a break point and how to single step. With just that, it will be so much easier to debug difficult problems!
PlatformIO is fragile. I've had to put my Python 3.6 behind Python 2.7 in the path to eliminate some of the problems. Twice today I've had to uninstall Atom, delete all the Atom & PlatformIO directories I could find and then re-install to eliminate some compile/run issues that popped up & wouldn't go away.
Yeah. I know what you are saying. I uninstalled Atom but as soon as it is re-installed it loads the sick and damaged PlatformIO stuff. When Atom gets installed, it shouldn't try to load previous add-in's without being told to do that. I hunted down some of those files (.Atom & .PlatformIO) in the C:\Users folder. When I got rid of those, I was able to do a clean install and get things working again. What a nuisance! I've told PlatformIO not to do any automatic updates. It seems those are responsible for some of the sickness.
Some of the errors were caused by PlatformIO not installing all the GCC files it needed. But then on the next install they were all there. Strange stuff.
Did you have to change how Marlin built to get the debug information available for GDB ?
Bob-the-Kuhn
commented
7 years ago Yes, I'm running Windows 10.
The good news is that GDP is included in the PlatformIO tool chain.
Once I got the platformio.ini file setup properly then it all worked. It took me a while to understand what I was looking at and what some of the messages meant.
I'll start putting together a "how to" doc.
GDB magically knows about the source level debug info. I expect it's also useful for assembly language but I haven't looked for it yet.
Roxy-3D
commented
7 years ago I'll start putting together a "how to" doc.
Please don't go too crazy... If I can just set a break point and single step, that will get me 90% of the way to where I need to be. (I know it is a lot of work to help pull others up behind you! Just one or two pages of text with screen captures (screen captures don't count on the 1 or 2 pages of text!) might be enough. No need to do a 700 page manual! )
Seriously... This will be a HUGE help!
Bob-the-Kuhn
commented
7 years ago Here's what I know.
Command entry through a tiny command shell window. Nasty. I think I'll see if any of the GDB GUIs listed in Atom help.
Roxy-3D
commented
7 years ago There are a huge number of people selling these on eBay. It almost looks like it is plug and play compatible with the nicer unit from Digi-Key:
I have a question about the very last step in the directions. At the very end it says:
On the J-Link 9-pin Cortex-M Adapter, solder a jumper across the NR1 pads. This brings TRST (CPU pin 2) into the debug probe.
If the debug cable is plugged into the board, doesn't the Segger J-Link gizmo have a way to control this? It would seem it would want to be in control of this because then it can let the processor run in non-debug mode if that is what the user chooses to do?
Bob-the-Kuhn
commented
7 years ago I like the price.
Segger doesn't have a V8 version of the J-Link. I wonder which one they cloned.
I've been chatting with the PlatformIO folks. After going into detail about the Atom/platformio debugging interface they came back (and) said to switch to VScode as that version of PlatformIO has a much better debug GUI. The screenshots back them up.
I'm now merrily enjoying the usual startup problems with VScode. I've been able to compile but not upload or debug. I'm waiting for the PlatformIO people to respond to my chat window messages.
Bob-the-Kuhn
commented
7 years ago Digikey has the 6" 10 position 0.050" cable assembly you'll need for $9. I didn't find anything like it on ebay.
It's a Samtec FFSD-05-D-06.00-01-N cable.
Roxy-3D
commented
7 years ago Actually... I know you will cringe... But what I was thinking of doing was gluing an adapter board like this: http://www.ebay.com/itm/112473010503 to the edge of the board. And then I can wire wrap all of the CPU (and other board wires) to the pins of the connectors on that board. And plug in the 30 pin J-Link cable to the right spot and run that to the J-link unit.
That was why I was asking about TRST pin and forcing it into debug mode. If the J-Link units can control that pin (and my guess is they can just because it is on the cable???) then I don't need to do anything. But if they can't, I could put a small switch there also so I can just flip the toggle to say I'm in debug mode or normal mode.
I've been chatting with the PlatformIO folks. After going into detail about the Atom/platformio debugging interface they came back (and) said to switch to VScode as that version of PlatformIO has a much better debug GUI. The screenshots back them up.
I've used MicroSoft's Visual Studio for a while. It would be too good to be true that PlatformIO can hook into that! MicroSoft's Visual Studio debugger is super powerful and so easy to use!!!
Bob-the-Kuhn
commented
7 years ago Is Visual Studio and Visual Studio Code the same thing? I doubt it. Visual Studio is big $$. VS code is free.
Yes, the J-Link units can use TRST if it's hooked up.
My main concern when I wired up the connector was being able to put the RAMPS board back onto the Re-ARM. The only advantage my approach has is the ugly is hidden when the RAMPS board is installed.
Bob-the-Kuhn
commented
7 years ago I think I've found a useful GUI GDB debugger. Unfortunately it's stand alone.
Download & install the Segger software J-Link Software and Documentation Pack and Ozone - The J-Link Debugger. After that just run Ozone.
When Ozone starts up select "LPC18xx.svd" and point it at the ELF. Just click YES when it complains about a missing license.
Under VIEW select Source Files so that you can set breakpoints in any source file.
It'll also download directly to FLASH in only a second or two.
PlatformIO seems to disconnect from the Re-ARM once it gets into the main program. Ozone doesn't have that problem after I disabled the WDT and fixed a couple of resulting complaints.
Roxy-3D
commented
7 years ago Wow! Good progress! My J-Link is ordered but it is coming from Asia so it probably will be a week or two before I can start soldering wires.
Is Visual Studio and Visual Studio Code the same thing? I doubt it. Visual Studio is big $$. VS code is free.
Hey! Check this out. I think it might be a crippled version of Microsoft's Visual Studio: https://techcrunch.com/2014/11/12/microsoft-makes-visual-studio-free-for-small-teams/
But even if it is crippled... It would still allow easy break points, single stepping and display of structures. In the Visual Studio, when you are debugging, you can just hold the cursor over any variable or structure and see what its value is. It is really easy and nice to use. Same thing for the argument to an if() or while(). It will evaluate the inside of paren's with the current values if you do that.
Bob-the-Kuhn
commented
7 years ago There is a Visual Studio Community and a PlatformIO page on integrating with it.
Following the PlatformIO instructions, I was able to create a project but I couldn't build an image.
I hope you have some experience with Visual Studio. There's lots of options & I'd rather be doing other things than learning Visual Studio.
Roxy-3D
commented
7 years ago I have a lot of experience with the 'real' Visual Studio. I'll see if I can figure out how to get the crippled version running with PlatformIO.
UPDATE: I've spent all day messing with this. I've got Visual Studio installed. I've got the PlatformIO IDE for Visual Studio installed. I can't figure out how to get the project generated and pulled into Visual Studio. Obviously the people that did the VSCode plug in for PlatformIO spent a huge amount of time doing the work. Can't they spend 10 minutes and give some directions?
Aaaarrrgggghhh!
Bob-the-Kuhn
commented
6 years ago @alex-gh - when I said "A $40 board that allows real instruction tracing." I was referring to the ice40-HX8K FPGA board. As of a month ago the Orbuculum site said it was a work in progress.
~I haven't found any details on programming the various debug macrocells in the LPC17xx. I saw the one for the STM32. Until I find the LPC17xx specific info I can't use the sigrok method. That means I'll need to use programs that already support SWO.~
I finally found the LPC17xx specific info so I can use the sigrok method. The sigrok WIKI page points to a STM32F1 file. Since the two processors are both M3 I can use the code as is. I'll need to provide register base addresses as the current LPC headers don't.
As best I can tell the following are the only systems/programs that support SWO that are not hardwired to use $1500 debug probes:
I think I'll play with OpenOCD this afternoon. EDIT 1 - couldn't get past the "LIBUSB_ERROR_NOT_SUPPORTED" error. I didn't find a generic USB driver that would work with the JLink. Looks like LPCXpresso is the next thing I'll try.
I have a LPC-Link2 on order. I expect I'll switch to LPCXpresso when it comes in.
GMagician
commented
6 years ago @Roxy-3D
I have a lot of experience with the 'real' Visual Studio. I'll see if I can figure out how to get the crippled version running with PlatformIO.
UPDATE: I've spent all day messing with this. I've got Visual Studio installed. I've got the PlatformIO IDE for Visual Studio installed. I can't figure out how to get the project generated and pulled into Visual Studio. Obviously the people that did the VSCode plug in for PlatformIO spent a huge amount of time doing the work. Can't they spend 10 minutes and give some directions?
Aaaarrrgggghhh!
I'm using VisualStudio community edition (for other purposes) but I was able to build marlin using platformIO core. I'm not sure the result I got but VS told me 1 project built...
Don't know where you are now with this and if someone else is interested in building marlin with VS but I can try to deepen the subject.
Roxy-3D
commented
6 years ago I'm not sure the result I got but VS told me 1 project built... Don't know where you are now with this and if someone else is interested in building marlin with VS but I can try to deepen the subject.
If you could .ZIP up the complete project... That would be very helpful. I bet I can figure out how to open it and see what it does.
GMagician
commented
6 years ago If you could .ZIP up the complete project... That would be very helpful. I bet I can figure out how to open it and see what it does.
I will...this evening I will rebuild the project...it was easy to prepare project and open it. for sure you have to install VC++ support in VS. Days ago I reset everything because I had problem with directories. VS project should be made inside marlin folder but platformio.ini is outside it. Now its 16:45 here in Italy
Roxy-3D
commented
6 years ago VS project should be made inside marlin folder but platformio.ini is outside it. Now its 16:45 here in Italy
Aaaarrrggghhh! I didn't know this. A .ZIP file of a working 32-bit Marlin project would be very helpful!
GMagician
commented
6 years ago Don't be angry...this evening I will do it and send a zip..be patient ;-) I made it in very first version of 2.0 refactoring now I have to check correctly what has to be done
GMagician
commented
6 years ago Hello Roxy-3D, here is vs project, with this version I get an error about git client not installed (never seen before). I had no time di look at it but I will.
this is command line to create project: platformio init --ide visualstudio --board megaatmega2560
Roxy-3D
commented
6 years ago Can Visual Studio compile both Re-ARM and AtMega-2560 at the same time?
this is command line to create project: platformio init --ide visualstudio --board megaatmega2560
I need it to compile (and Debug!!!!) the Re-ARM board. The whole reason for this exercise is supposedly the Visual Studio debugger works much better and is easier to use than the Atom stuff.
I presume I can create the project by doing a platformio init --ide visualstudio --board rearm ?
GMagician
commented
6 years ago launching platformio boards you will get all supported boards and ID to use in --board switch. Check in the list the one you have and finally yes, I compiled for mega2560 and platformio will be able to compile for different platform...on window system it will automatically download all build chains
The only bad thing about built project is that all files are listed, they are not divided in folders. I will try to use a different approach, create project using folders, and then add build chain to the project. If I will succeed I will share it
alex-gh
commented
6 years ago Finally soldered the wires for the debugger.
Now to find a working probe...
Bob-the-Kuhn
commented
6 years ago Just using the serial debug pins. Not as much work & does everything.
GMagician
commented
6 years ago @Roxy-3D Here I'm back, I tryed building project, now everything works correctly. Have you succesfully compiled for re-arm?
1) Install git 2) Open git bash in "Marlin" root folder type "platformio init --ide visualstudio --board [yourboard]". This will create a "lib" but who cares. I tryed to build project directly from VS but it will create the same project layout....flat, no hierarchical layout. I'm used to C# and layout is better than C++ Googleing around I found that you can switch to Folder view (solution explorer top menu there is a button to switch) or a VS extension (not tested) at "https://github.com/reloZid/vc-fileutils"
Hope to help someone with this
Roxy-3D
commented
6 years ago @GMagician
I just saw your instructions now. I'll give that a try!!!!
github-actions[bot]
commented
3 years ago This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
A while ago we had a big discussion on what ICE made sense for the AVR's. Some people got MK-II's and others got the Dragon.
Are those the 'right' tools for doing serious debug on the 32-bit platforms? For the Re-ARM board, what are the options available?
For example, right now I'm looking for a lock up problem when my machine does a small Z movement. If I could stop the processor and see where it is executing... That would help a huge amount in trying to locate the source of this bad behavior. But being able to set break points and being able to single step would be very valuable too.