MDK error when attaching: "The Moto Mod can't connect and isn't working. Try attaching it again"

Did you switch to Developer Mode before flashing (although flashing should not be allowed unless you did)?

Did you ensure you're using VID=0x42 in the firmware you built?

As for openocd, really need to see the exact error message.  I have a guess, but I'd like to see the error (and double check on my setup).

The good news is, since openocd is Serial Wire Debug you really can't brick your MDK.

Hi Christian!

Thanks for the response. I'm definitely using VID 0x42. I've attached screenshots of OpenOCD's output. The first image is running the command to flash it, the second is running the command again with the "-d 3" option which shows a little more information about the error.Any thoughts? Also, good to hear that it's not brickable haha.

Thank you,

Andrew Afflitto

I spent some time with OpenOCD. When I try to connect using the GDB command "target extended-remote localhost:3333" the connection times out. Is there any way to debug this further? Thanks.

Christian, I am seeing the EXACT same issues with my system that used to work.  Previously you helped me get usb2 working on my two MotoMods.  Today I did a git pull on anything that needed it and rebuilt everything for compute (so I can do USB3).  Now I error out just like Andrew.....

This is a setup that used to work, the only difference is that I grabbed the more recent updates.  I verified that my system is seeing the FTDI part when it is plugged in, so it isn't like it is dead or something....

Some more information.  I tried rolling back my nuttx and muc-loader to the hashes from the end of JAN and rebuilt, but that didn't seem to do anything.  I tried different USB cables, no dice. I tried with and without the protocards, no dice.

The error that get printed as debug: "_ftdi_swd_run_queue(): JUNK DP read reg 0" seems to mean that there is a bad connection (though I am not sure why that would be).

I am running Ubuntu 14.04 if that helps any.

Jason,

I just took a look at Motorola's openocd repository, and noticed they pushed a commit last week which changes ftdi.c in the function you noticed is throwing the error. I won't be able to try this on my laptop for a few hours, but you might want to pull down the new commits from openocd and compile it to see if anything changes. Not sure why your's would all of a sudden break, but this seems like it might have to do with it.

Andrew, no dice.  I blew away my openocd build and pulled it down fresh and still get the same error.  Like you said, it is very weird that it worked and now doesn't, yet you never got it to work and have the same issue.....

Also, I mis-typed my error message in a previous post, the value returned was all F's, not a 0: "Debug: 367 112 ftdi.c:1148 _ftdi_swd_run_queue(): JUNK DP read reg 0 = ffffffff"

Jason,

I tried it last night as well but couldn't get it to work either. Looking around, I found the same thing you did that the "JUNK DP read reg 0 = ffffffff" seems to imply that the FTDI can't connect to the muc. The FTDI is definitely communicating with openocd, as when I unplug the USB I get a different error about not being able to connect to the adapter. So I'm thinking that maybe the CPU isn't actually resetting, which would cause the FTDI to not be able to connect if it were in a low power mode. This weekend I'm gonna try to look at the schematic as well as the actual FTDI commands to make sure the configuration file doesn't have any errors and is indeed resetting the CPU. I'll let you know if I find anything out.

Andrew, the USB is definitely enumerating as I can run udevadm and see it enumerate when I plug in the USB:

So we know USB is fine (as you also pointed out when you tried to run openocd with nothing connected), so we can rule that out.

I am very confused as to why when I blew everything away, re-downloaded everything, and checked out the hashes from the end of JAN (which should have been what I was running off of when things worked), stuff still did not work.

I think I agree with you that something is up with the muc and it needs to be brought out of a weird state somehow...

Going to take a closer look later on, but this may be helpful: https://developer.motorola.com/build/tools/debug-and-log#logging. It says sending characters to the NuttX terminal should wake it up from a sleep state.

Also, I was able to flash the MDK using openocd once but it was a while ago. I then started using the MDK Utility, which worked fine until this past flash. I flashed custom firmware, so it's possible there is a bug or other issue with my code. Not sure why Blinky isn't working for you, especially because you used the exact version that worked for you previously. The version that you flashed that started causing these issues, did it include modified firmware or was it a stock configuration?