chipKIT® Development Platform

Inspired by Arduino™

chipKIT CEREBOT MX7 ck

Created Wed, 18 Jan 2012 01:56:32 +0000 by lloyddean

lloyddean

Wed, 18 Jan 2012 01:56:32 +0000

Might I express my disappointment concerning the documentation on getting this board working with the latest MPIDE.

What would be most useful is something that shows, step by step, how to configure the board and which of the 4 USB ports to use when working with MPIDE.

As it is I'm not sure if I'm the problem or something is wrong with the board.

Meanwhile how about little preview of the new improved documentation right about ...

Edit Additional Information, Mac OS

Finally got the Serial ports to be recognized when POWER SELECT set as EXT and connected to an external power brick.

Unfortunately upon any attempts to upload I receive:

avrdude: stk500_2_ReceiveMessage(): timeout

So how do I determine if an Mpide compatible boot loaders is actually installed on the board?

lloyddean

Sun, 22 Jan 2012 19:09:36 +0000

Anybody give me an idea as to why my questions seem to take forever to get any response?

KeithV

Thu, 26 Jan 2012 17:38:36 +0000

llyod, (or is it Dean?),

Sorry you are having trouble. I use all of the boards and was able to figure out what to do from the document, but understand that the MX7cK is not as clear on the board as the MX4cK. So here are some things to check. I am assuming you are on a PC; although it shouldn't make any difference.

  1. The board comes from Digilent configured for MPLAB, not MPIDE. You must configure it for MPIDE.

  2. To do so, make sure the POWER selection J3 is set to jumper the UART; not DEBUG as shipped. Also make sure JP11 is jumpered (shorted) as this allows MPIDE to "reset" the board and causes the bootloader to accept you MPIDE sketch on upload; as shipped this is NOT jumpered.

  3. The MPIDE UART micro USB plug is the one closest to the power switch, this is documented in the doucment; but I agree it would be nice if it were clearer on the board.

  4. Make sure you turn ON the power switch. While the USB port will be recognized by the PC without the switch being ON, you will not be able to upload a sketch if the power switch is OFF. Make sure the power switch is ON.

  5. Make sure you select the correct USB port and the MX7cK board from within MPIDE, again this is NOT the default for MPIDE. This is under Tools\board, and Tools\Serial Port in MPIDE.

  6. You should now be able to upload a sketch from MPIDE. However, it takes a few seconds after you upload a sketch for the sketch to start. This is because the bootloader has a delay after the reset before the sketch starts execution. A bit annoying and can be fixed, but that is how the stock bootloader works now.

Hope this helps; good luck

lloyddean

Thu, 26 Jan 2012 19:28:48 +0000

Hello Keith,

Thanks for taking the time and effort to respond. The first name is indeed Lloyd and I'm on Mac OS 10.7.2

I can't see anything I have configured different than described.

With the board facing me such that I can read the silk screen labels:

I connect the USB cable to the port located at the botton left side of the board to the left of the power switch.

I have the "Power Select" jumper set at the bottom most position labeled "UART".

I have the jumper block JP 11 jumpered.

Power On

LD8 Power indicator light comes on solid red. LD5, LD6 and LD7 light yellow and stay on. LD1 flash green for approximately 15 seconds. LD1 Briefly goes out. LD3 Comes on followed a second later by LD1. A fraction of a second later they turn off and LD2 and LD4 come on. A fraction of a second later they turn off and LD1 and LD2 come on. And we cycle through the previous two states forever alternating.

Mean while back in Mpide.

Have selected "Cerebot MK7ck" from the the "Board" sub menu of "Menu Tools". Two new serial ports have showed up. I can select either of the 'cu' or "tty" versions wit the same result.

Click the second button from the left in the IDE's toolbar at the top left of the Windows to compile and upload to the board results in -

Binary sketch size: 6876 bytes (of a 520192 byte maximum) avrdude: stk500_2_ReceiveMessage(): timeout avrdude: stk500_2_ReceiveMessage(): timeout

... repeating till the IDE is quit ...

This is nothing different than I've had happen from minute one ...

Lloyd

KeithV

Thu, 26 Jan 2012 22:52:38 +0000

Lloyd,

You said:

Two new serial ports have showed up. I can select either of the 'cu' or "tty" versions wit the same result.

Unfortunately, I am a PC user, so I do not know the specifics here, but.....this is odd that 2 serial ports showed up in MPIDE, unless you have MPLAB also plugged in the other Debug Micro USB port; I think only 1 new com port should have shown up. If you have MPLAB plugged into the Debug USB port on the MX7cK, unplug it.

Because MPLAB will hold the reset line, if you plug in MPLAB in the debug USB, it will prevent MPIDE from loading. There are ways to get both MPLAB and MPIDE to be used concurrently, but that is for another day.

The other thing; I think I remember seeing that there is some driver needed on a MAC (A step you don’t have to do on a PC) to get MPIDE to recognize the serial port. If that serial port is not being set up correctly, well than all bets are off. And if you do not have anything plugged into that debug USB port, it is strange that 2 new serial parts are showing up.

However, to be honest, it sounds to me like something was programmed on the board at least once. If nothing has ever been loaded on the board, then the bootloader has nothing to load and it will sit in the monitor UART1 state and LD1 should stay blinking quickly. If something has ever been loaded, after a few seconds LD1 will stop blinking and the bootloader will load the program from flash. The fact that your LED1 stops blinking tells me that something was once loaded into flash, either via MPIDE or MPLAB.

Have you ever used MPLAB on this board?

Have you ever successfully programmed a sketch on the board?

You might try reloading the bootloader. You can get a copy of the bootloader from the Digilent website

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,396,986&Prod=CEREBOT-MX7CK

But you will need to program this with MPLAB. Do you know how to do this?

Another thing I would check before attempting to reprogram the bootloader. Make sure JP11 is shorted, that is, make sure the connector is not loose or is not really shorting out those pins. I have had a few loose jumpers that really didn’t jump.

lloyddean

Fri, 27 Jan 2012 05:30:05 +0000

Keith,

Thanks again for the response.

The serial drivers are indeed installed and working properly. The multiple items showing in the menu is normal. The IDE and serial ports have been working fine with the Arduino, chipKIT UN32 and MAX32 boards since last summer. Yes I am using the lastest version of Mpide and its include serial drivers in this attempt at getting the MX7ck board to accept a program.

No I haven't bothered trying MPLab X yet (it's the only version available for Mac OS).

I received the board new. It's never had a program upload to it by myself.

My thinking was perhaps the bootloader was not installed or defective.

I have acces to MPLAB from VMWare running on this Mac but haven't yet tried using it with this board.

Thanks for the heads-up concerning the jumper-block - I'll check it in the morning.

KeithV

Fri, 27 Jan 2012 17:42:00 +0000

Lloyd,

I routinely reprogram the bootloader with MPLAB, I don't use MPLAB-X as from what I can tell it doesn't work so well; I have tried but have lost faith :?

But, it doesn't really matter as long as you can get the bootloader programmed.

I just tested the bootloader as downloaded from Digilent and it seems to work just fine on the MX7ck. So try reprogramming the bootloader.

If that works and you really believe you were shipped a bad bootloader, we probably need to know that and check production. Maybe I will put a request in to check it anyway...

I have to admit, I think I noticed a difference between the bootloader up on the web site and the one I got pre-installed as well. My pre-installed one did work, but I thought as it waited monitoring the UART that LED1,3 & 2,4 alternated blinking instead of just LED1 blinking. Clearly the one that downloads form Digilent, only LED1 blinks.

lloyddean

Fri, 27 Jan 2012 20:37:56 +0000

Keith,

MPLAB X is all that is available for Mac OS.

You've said reloading the bootloader is only possible from MPLAB not Mpide. Why then is there an option in Mpide to do so?

Thanks

KeithV

Sat, 28 Jan 2012 00:49:21 +0000

If you are talking about tools\burn bootloader;.... hmm... look under the programmers and you will not see an appropriate programmer to use (The MX7cK uses a licensed Debugger). So basically programming a chipKIT from MPIDE is not supported.

Having said that, I am not absolutely sure of my answer, but I think I am correct. I have always done if from MPLAB. Send a message to Rick Anderson, he will know for sure.

Oh, I have put in a request to have the MX7cK & MX4cK pre-installed bootloaders checked. Let me know if loading a new bootloader fixes your problem.

lloyddean

Sat, 28 Jan 2012 03:19:26 +0000

If indeed it is NOT supported then perhaps the Menu Item should be adjusted to reflect that fact when this board is selected as a target. Simply nothing happening when it is selected is NOT enough of a clue, at least in my opinion.

Thanks for the conversation.

lloyddean

Sun, 29 Jan 2012 02:48:56 +0000

Keith,

Can you point me at anything that documents the procedure for burning a bootloader to this board from within, I guess MPLAB under VMWare on, Windows (7 if it makes any difference).

KeithV

Sun, 29 Jan 2012 07:07:37 +0000

Let's see if I can give you a quick lesson.

  1. Set the MX7cK up for MPLAB, that is put the power switch to DBG and unjumper JP11

  2. Plug the USB micro cable into the USB DBG port next to the one you use for MPIDE on the MX7cK

3 Start MPLAB, my instruction are for MPLAB, not MPLAB-X, so I am assuming Windows.

  1. From the MPLAB dropdown bar, select Configure->Select Device->PIC32MX795F512L

  2. From the MPLAB dropdown bar, select Programmer->Select Programmer->Licensed Debugger.

  3. You will see in the MPLAB output window a bunch of stuff saying you are connecting to the board. You may see it "updating" the programming software; allow it to do this. IF it updates, that will have several automatic steps. But when it is done you should see that the Device is Detected with a device ID number.

  4. Download and unzip a copy of the bootloader from Digilent, here is the link: http://www.digilentinc.com/Data/Products/CEREBOT-MX7CK/chipKIT_Bootloader_MX7ck.zip

9: From MPLAB, do a File->Import and then browse and select the bootloader you just downloaded... make sure you unzipped the bootloader first!

  1. Once the bootloader is imported to MPLAB select Programmer->Program

  2. You will see Program and verify in the MPLAB window when complete.

  3. Exit MPLAB.

  4. On the MX7cK move the power selection back to UART and reshort JP11.

  5. connect you USB cable to the UART, the MX7cK will power up and eventually you should see LED1 just blinking; this means the MX7cK is waiting for a sketch uploaded.

  6. In MPIDE make sure you select the correct serial port and board.

  7. build a basic skeck and see if it uploads from MPIDE.

lloyddean

Tue, 31 Jan 2012 01:35:53 +0000

Keith,

Thanks very much for the clear and concise instructions in reprogramming the CEREBOT MX7 ck bootloader. Everything appeared to go as you described.

Power Select jumper block placed at UART JP11 jumper block in place USB plugged into port to the left of the power switch

Power On LD8 lights At 4 seconds LD5, LD6 and LD7 lights Another 4 seconds and LD5 and LD6 goes out

Attempts at compiling and uploading a sketch resilt in:

Binary sketch size: 6876 bytes (of a 520192 byte maximum) avrdude: stk500_2_ReceiveMessage(): timeout avrdude: stk500_2_ReceiveMessage(): timeout avrdude: stk500_2_ReceiveMessage(): timeout ...

End result a new light show but still unable to upload a program to the board.

KeithV

Tue, 31 Jan 2012 03:18:41 +0000

I am sorry this is so frustrating!

So after reprogramming the bootloader, but before an attempt to upload any sketch, did LED1 just blink? From you discription it sounds like LED1 and 2 just stayed ON? On my personal bootloader (I have my own for development) I keep LED2 ON, but on ALL bootloaders (all that I know that exist) LED1 will blink before the first sketch is loaded.

I'm not done helping you yet, but let me know if you have access to windows; if we can get it working there... we know the board is okay. If it is with Mac OS.... well I can't help you there.

So get a windows machine with MPLAB and MPIDE on it if you can.

lloyddean

Tue, 31 Jan 2012 04:48:36 +0000

Hello Keith,

Yes before I "attempted" the upload it did indeed blink for over an hour before I could get to it. When the upload started the blinking LD1 went out!

For all intents and purposes I have a Windows 7 Ultimate box running under VMWare Fusion 4.x on Mac OS. This is how I was able to burn the downloaded bootloader. I've had no problems throwing WIndow's software at it. Everything seems to work just fine on it. I just DON'T LIKE Window's and the board belongs to someone else that is Mac based as well.

Again I am able to work with the chipKIT UNO32 and MAX32 boards without problems.

Suggestions?

KeithV

Tue, 31 Jan 2012 20:01:34 +0000

Well not really. It seems to me that the reset line is not being pulled by MPIDE when programming, for whatever reason. JP11 is supposed to enable this. This could be a defect somewhere on the board, but just seems so unlikely.

Since the LED1 was blinking, and you verified it, then I would say the bootloader was up and running. Something goes haywire when you problem.

If it were here, I would attempt to program it from my computer, if it did not work I would have to say a hardware problem. It is too bad as clearly most everything works as you can program through the DBG port.

The is a way to program a sketch through the debug port, but it requires the use of MPLAB. Do you want to try and program through the DEBUGGER.

lloyddean

Tue, 31 Jan 2012 23:27:57 +0000

Keith,

So you're all out suggestions then?

Here is the deal - the plans are to use these in a educational setting where each student uses their personal machine for development outside of class time. As such we have mixtures of computing platforms. So there is a difference between what I can do and what the students can do as well.

I've tried replacing the USB cable - no difference. I've tried replacing the jumper shorting block - no difference. Disconnecting and reinserting the USB cable gets LD1 blinking again.

Two of these boards were ordered and I have one of them. I can arrange to have the second one this weekend and see what happens with it but in talking with the individual that has it, if I understand correctly, the results are the same for him as well.

KeithV

Thu, 02 Feb 2012 00:47:32 +0000

Well this sounds well above my pay grade :roll:

What I can do is contact Joe at Digilent and get him on this thread. If there is something wrong with the boards we need to fix that. If it is the Mac OS, well then we should at least understand what the issue is.

The bootloader for the cK products are different than the Max32 and Uno32. Maybe there is a Mac OS issue in the difference. I would love to try your board on my machine, or a real Windows machine. Fundamentally I believe your Window's emulator is fine, but since we are having such a problem; now it is time to find out what it is! Or where it is.

In contrast to your experience, I love the cK boards!

Let me ping Joe.

GeneApperson

Thu, 02 Feb 2012 01:35:09 +0000

LLoyd,

What version of MPLAB do you have on your computer? There is a known bug in the debugger firmware in MPLAB 8.80 that could cause the behavior that you are experiencing (although a new board that has never been connected to MPLAB shouldn't experience it).

If by any chance you do have MPLAB 8.80 on your computer, please upgrade to 8.83 or later and then reconnect your board to MPLAB so that it can upgrade the dedbugger firmware.

Gene Apperson Digilent

lloyddean

Thu, 02 Feb 2012 01:55:59 +0000

Hello everyone,

Gene I was aware of that issue from elsewhere, the currently installed version is MPLAB v8.83.

As I related above, burning the bootloader, from MPLAB (and thus VMWare Fusion on Mac OS), seemed to go fine and no problems were reported.

KeithV

Thu, 02 Feb 2012 04:22:04 +0000

Lloyd,

Over dinner I was thinking of all of the things that would cause AvrDude to have a problem. I looked back through this thread and you just stated, the latest MPIDE, which one is that? 1221? or one of the newer test builds?

Okay, and just to track down all possibilities, would you make sure the board you are selecting is the Cerebot MX7cK and NOT the Cerebot 32MX7? I know I'm grabbing at straws here... but it has to be something!

lloyddean

Thu, 02 Feb 2012 04:41:32 +0000

Keith,

Sorry to have spoiled your dinner!

Right now I've installed from mpide-0023-macosx-20111221.dmg. Which I beleive is the release version.

For your information now that we have a different behavior after having burned the downloaded bootloader I have just retried uploading my example program from the latest version of the Windows Mpide. It now works there so the board appears good! Where as it didn't work with what I recieved pre-installed on the board.

So, the board is now working and it's down to something in either the Mac install of Mpide or the provided serial driver also included with this version of the Mpide.

We're making progress we really could use a working Mac OS programming emvironment as well.

EDIT:

And yes I have the correct board selected in the Mac OS version of Mpide.

KeithV

Thu, 02 Feb 2012 16:59:00 +0000

Excellent work!

Don't worry about my dinner; I know how it is to buy something, want to get going with it, and then spend days wondering why it doesn't work! Very frustrating! I am glad that we verified that the MX7cK is okay.

As for how to move forward... yeah, you got me; I am not a Mac guy, not even a little bit. Don't get me wrong, there is nothing wrong with a Mac, it is just my background is all Windows and that is all I have here.

If it were my guess, and now that is all it is, I would guess it has something to do with the serial driver shipped with MPIDE. You could try and see how the MPIDE 1221 serial driver works with a Max32/Uno32. I know in the past you had success, but are you having success today? This would give you a hint as to the driver status. You know, I don't even know for sure who makes those Mac serial drivers, but that is where I would start. I am sure Rick Anderson would know the answer to that question (although I think Rick is a Unix guy himself).

Thank you for the info on the pre-installed bootloader; at Digilent we have started the process of determing what happened there and how to correct it. Unfortunately these boards get manufactured in quantity, then when something goes wrong we need to fix it, Ouch! Out-of-the-box my MX7cK did work with the pre-installed bootloader, but yours did not... and the pre-installed bootloader is different than the one we have posted on the Digilent site... so clearly something went sideways. Thank you for your help!

lloyddean

Thu, 02 Feb 2012 17:26:57 +0000

Just a reminder - Mac OS 10.6 and 10.7 are certified UNIX!

lloyddean

Thu, 02 Feb 2012 17:54:31 +0000

Keith,

Further feed back - I've been able to successfully upload my test program from Mpide to -

Arduino UNO Arduino Mega 2560 chipKIT UNO32 chipKIT MAX32

lloyddean

Fri, 03 Feb 2012 02:32:10 +0000

So, can I assume someone is still looking into this or am I just hanging ...

KeithV

Fri, 03 Feb 2012 05:20:01 +0000

Thank you for the feedback.

Will you do me a favor? Attached is my personal bootloader that I built for the MX7cK. I built this under MPLAB, not MPLAB-X. So this is totally unofficial. I made some personal modificaitons for my likes, but it would be interesting to see if it works for you? If it works, that will tell us that we picked up something bad as I got the sources off of github myself.

You need to unzip it of course, but then follow the same bootloader load instruction I gave you before. Let me know if it works?

KeithV

Fri, 03 Feb 2012 16:22:52 +0000

Lloyd,

I went ahead and asked Rick/Mark about your problem and the error you are getting. I think Mark wrote the bootloaders for the Max32/Uno32 so he would know. Anyway Mark said that the error you are getting is usually caused by, and I quote:

On 2/3/12 11:11 AM, Keith Vogel wrote: 
Oh, and he is getting an error form avrdude:
avrdude: stk500_2_ReceiveMessage(): timeout
KeithV

Keith
That error normally means he has the wrong 
serial port selected or the wrong baud rate.
Mark

So Lloyd, I am thinking the place to look is very closely at the serial port somehow.

lloyddean

Fri, 03 Feb 2012 19:15:40 +0000

It is the Mpide that populates the "Tools" submenu "Serial Port".

These two serial port selections show up after the CEREBOT MX6 ck board is powered on and disappear when powered down or the USB cable is dissconnected.

cu.usbserial-A700h3AO
tty.usbserial-A700h3AO

It is also the Mpide that sets the baud rate. The only control the user has is to install the drivers provided.

And it would be useful to have an uninstaller as part of the installer.

KeithV

Fri, 03 Feb 2012 23:38:50 +0000

Sorry, not a lot of help here...

I looked through the code, there is no appearent difference for any MPIDE OS. Did you try the bootloader I sent you a few messages ago?

lloyddean

Sat, 04 Feb 2012 18:54:58 +0000

Keith,

End result the same.

LD1 was flashing til program upload started.

LD8 (Power) on. LD7 on.

Binary sketch size: 16440 bytes (of a 520192 byte maximum) avrdude: stk500_2_ReceiveMessage(): timeout avrdude: stk500_2_ReceiveMessage(): timeout avrdude: stk500_2_ReceiveMessage(): timeout

KeithV

Sat, 04 Feb 2012 19:29:15 +0000

Lloyd,

We spent some time verifying what is being preloaded on the boards and infact it is the same bootloader as what is on the Digilent site. What made for the different light show is that Digilent programs a test sketch on during manufacturing to make sure it can be programmed, and the light show was the test program running. I personally binary compared the production bootloader to the one on the Digilent site, it is the same. I can not explain why you had a problem initially loading from Windows, I suspect something was already hosed by the time you tried that.

This all boils down to your mac not talking to the the board, most people we have talked to all say it is probably some kind of configuration problem with the mac and the serial ports, be it baud rate or port assignement. It is perplexing that you have no problem with the Max32; however... with each new device a new serial port is assigned, if an old device is plugged in, the old serial port is reused, that is at least how it works on Windows. So it is possible that you have the serial port set up correctly for the Max32, but not the MX7cK, and the Max32 would continue to work and not the MX7cK. I looked in the bootloader code and the serial port needs to run at 115200 baud; although I think MPIDE programatically set this up as even on my Windows machine, Windows see it at 9600 baud. If you have a friend with a Max32/Uno32, try to program his; if it works... that is even more preplexing, if it does not work, then we know it is a mac configuration problem.

As we scratch our heads, one of the guys at work had the following random thought; and again, remember we are a Windows shop... so mac is not what we do very well.

The Random thought:

Someone mentioned that he is using VM-ware to run the windows on the mac, I am sure you have already tried this but if he is using vmware has he allocated the USB to windows OS he’s running they don’t always natively add to the currently running operating system you have to connect to the usb through the OS on screen drop down menu.

Lloyd, I really don't think there is anything wrong with the bootloader or board; that is my best understanding today. You aren't even getting to the board which really points to a serial port connection problem, and that would be on the mac. And I am sorry, that I can't be more help, I am just not a mac guy. :cry:

lloyddean

Sat, 04 Feb 2012 22:40:08 +0000

Keith,

Are you with Digilent? If so why don't you have a Mac there to do testing on?

Mac hardware can boot any of Mac OS (true certified UNIX), Windows and LINUX all three of which are touted as compatible with the Arduino IDE and API.

The Window mono culture is fragmenting. You're in the trenches but aren't seeing the changing landscape.

I REALLY suggest Digilent take the Mac market more seriously and do testing against it.

Thanks for the assistance but unless we get this board working on all three platforms the schools I'm working with just can't use this board. Nice tho it is!

lloyddean

Sun, 05 Feb 2012 00:06:16 +0000

Keith,

Holding the SHIFT key down when hitting the compile and upload button results in:

Binary sketch size: 16440 bytes (of a 520192 byte maximum)
/Applications/Mpide.app/Contents/Resources/Java/hardware/tools/avr/bin/avrdude -C/Applications/Mpide.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf -v -v -v -v -p32MX795F512L -cstk500v2 -P/dev/cu.usbserial-A700h3AO -b115200 -D -Uflash:w:/var/folders/ny/d96l2tgs13g6fjmql1574wzm0000gn/T/build1299027410785252238.tmp/ArduinoFunctionTimer.cpp.hex:i 

avrdude: Version 5.8cvs, compiled on Jan 15 2010 at 17:27:01
		 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
		 Copyright (c) 2007-2009 Joerg Wunsch

		 System wide configuration file is "/Applications/Mpide.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf"
		 User configuration file is "/Users/lloyd/.avrduderc"
		 User configuration file does not exist or is not a regular file, skipping

		 Using Port                    : /dev/cu.usbserial-A700h3AO
		 Using Programmer              : stk500v2
		 Overriding Baud Rate          : 115200
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_2_ReceiveMessage(): timeout
avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]

KeithV

Sun, 05 Feb 2012 19:49:21 +0000

Lloyd,

I went to my windows installation and intentionally selected the wrong Serial port and got exactly the error you are getting It is my best understanding that you are somehow selecting the wrong serial port. This is exactly what Mark Sproul said in his response.

I know you are frustrated, and so am I. There is nothing more that I would like than for you to have this work. But every indication I have is that you have somehow selelcted the wrong serial port. I can not help you with that on a Mac.

MPIDE is the component that runs on Mac, Windows, and Unix and is built and maintained by Furbar Labs, that is Mark and Rick. I would start a dialog with Mark as he would know a heck of a lot more than I in this matter. These guys are good guys, they will do what they can to help.

lloyddean

Mon, 06 Feb 2012 00:13:17 +0000

Keith,

(Sorry I haven't figured out how to use this sites posting editor to inline the images correctly - but you have me pissed off at the moment.)

Installed 'Mpide' and its included Serial Driver from this file "mpide-0023-macosx-20111221.dmg" on the Digilent site.

Run Mpide

Select board:

Before the board is plugged in the "Serial Port" selection menu looks like this:

After the board is plugged in the "Serial Port" selection menu looks like this:

Now perhaps you can tell me how "I" managed to select the wrong Serial port?

Deflection of responsibility and blame the user. A true Window support staffer!

KeithV

Mon, 06 Feb 2012 16:12:23 +0000

Lloyd,

I understand your frustration; I would like to figure this out as well. It is important to Digilent and to me. Notice that I am still attempting to help you even though this is way outside of my expertise. FYI: I do work for Digilent, but physically reside 340 mi from corporate.

I noticed that you have in your listing:

[color=#804000]System wide configuration file is "/Applications/Mpide.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf" User configuration file is "/Users/lloyd/.avrduderc"[/color] [color=#BF0000]User configuration file does not exist or is not a regular file, skipping[/color]

Please compare what I get when I select an invalid port:

Binary sketch size: 7316 bytes (of a 520192 byte maximum) C:\Users\KeithV\Documents\ArduinoMPIDE1221\mpide-0023-windows-20111221\hardware/tools/avr/bin/avrdude -CC:\Users\KeithV\Documents\ArduinoMPIDE1221\mpide-0023-windows-20111221\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -p32MX795F512L -cstk500v2 -P\.\COM4 -b115200 -D -Uflash:w:C:\Users\KeithV\AppData\Local\Temp\build6903253099853869011.tmp\BlinkMX7.cpp.hex:i

avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2009 Joerg Wunsch

     System wide configuration file is "C:\Users\KeithV\Documents\ArduinoMPIDE1221\mpide-0023-windows-20111221\hardware/tools/avr/etc/avrdude.conf"

     Using Port                    : \\.\COM4
     Using Programmer              : stk500v2
     Overriding Baud Rate          : 115200

avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] avrdude: Recv: avrdude: Recv: avrdude: stk500_2_ReceiveMessage(): timeout avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14] avrdude: Recv: avrdude: Recv: avrdude: stk500_2_ReceiveMessage(): timeout avrdude: Send: . [1b] . [01] . [00] . [01] . [0e] . [01] . [14]

KeithV

Mon, 06 Feb 2012 21:42:00 +0000

Lloyd,

The MX7cK uses a UART to communicate with avrdude. As you can see avrdude was compiled back in 2010, so not much has changed with it. Since we are using a stardard UART, the MX7cK could care less who it is talking to; and avrdude hasn't change. If the MX7cK can talk to avrdude in any properly compiled context, it should work in every properly compiled context. So it should not matter if from Windows, or Mac, or Unix.

However it is not working for you! It is clearly a communicaitons problem and we must realize it is either a port issue, or a baudrate issue. I don't know what the missing configuration file means on your end, but on our end I took a very close look at the baudrate calcuations for the UART; and it is slightly off...

Now realize, baudrates ARE going to be off some, it has to do with the period of the system clock and how closely it can match up with the baudrate requested. However, the wrong formula was use, and the baudrate was off very slightly.

The existing baudrate works out to be at 113636 as compared to the desired 115200, a difference of -1.36%. When recalculated using the correct formula the baudrate comes in at 116279 or +.97% difference. I have seen in documents functional baudrates as far off as 1.1%. Unfortunately, 115200 is one of the worst baudrates to hit with an 80MHz clock; and the UART. Your Mac, as well as my PC is probably not going to hit this baudrate exactly either. The question is, what is too far off? Thinking about this, this can have a machine to machine variance, as machines have different clock speeds, they could be high or low, their clocks can drift. Your Mac might have been high, and the MX7cK was low; I don't know.

I have attached a bootloader that I built that corrects the baudrate to the best it can be at 116279; it works on my PC. If you care, program it and give it a try.

lloyddean

Tue, 07 Feb 2012 02:19:37 +0000

Keith, thanks for continuing to look into this. I'm busy with something else at the moment and will get back to you shortly.

Please understand my anger was simply at the continued implications that "I" had somehow not selected the correct serial drive which given the IDE was NOT possible as the choices were provided by the IDE thru negotiating with the System Software . I am not an idiot and am perfectly able to make a selection from the serial ports offered by the IDE.

Something is wrong somewhere, and it is NOT me, and I am in the process of tracking it down.

I will note that I have tried removing all FTDI serial drivers and verified that the IDE is unable to offer me a serial driver for ANY of the Arduino, chipKIT or CEREBOT boards. Reinstalled the ONE driver provided with the IDE and was able to upload to the various Ardunio and chipKIT boards but NOT the CEREBOT board. So the driver is installed and it works. Just not with the CEREBOT MX7 ck board.

The error message "User configuration file does not exist or is not a regular file, skipping" is just stating that "I", the user, have no custom configuration file - not that something vital is missing.

KeithV

Tue, 07 Feb 2012 15:54:03 +0000

Lloyd,

I understand you frustration; you want this to work and it doesn't. At no point did I ever think you were an idiot, but something is clearly wrong. At this point all possibilities must remain on the table, even level 1 problems (Like I forgot to turn the power on). Please understand, I do not have a Mac and even if I did, I wouldn't know as much as you on how to use it; that is just a fact. So I need to depend on you for the Mac part; I will work the bootloader part. Hopefully together we can figure this out and get it to work; we will all win if we can, and that is our common goal.

When you get a chance try the attached bootloader in my previous response with the corrected baudrate. I will be very happy if this is the problem.

If not, I would love to somehow remotely debug an upload; but I haven't figured out how to debug without being in the same place.

I have to say, it is extremely interesting that you CAN upload to a Max32/Uno32 (which one is it?) as these have basically the same bootloader as I am giving you; with one very notible exception, the ones I am giving you are built with a different compiler. The source was taken off of Github, it should be the same.

lloyddean

Tue, 07 Feb 2012 17:53:00 +0000

I have to say, it is extremely interesting that you CAN upload to a Max32/Uno32 (which one is it?) ...

Both actually! I am able to upload to any of these boards without problems -

Arduino Uno Arduino Mega 2560 chipKIT Uno32 chipKIT Max32 LeafLabs Maple

KeithV

Wed, 08 Feb 2012 00:31:15 +0000

Let me know how that new bootloader works.

I may have to attempt to compile with the old compiler.

KeithV

Wed, 08 Feb 2012 00:34:28 +0000

Do you have a picKIT3? or something you can program the Uno32/Max32 with from MPLAB?

KeithV

Wed, 08 Feb 2012 20:11:33 +0000

Lloyd,

We found the problem; and it is obsure but a manufacturing problem with both the MX7cK and the MX4cK. However, it can be fixed, you can fix it.

Turns out that a resister was loaded that should not have been loaded. That is resistor R159 on the MX7cK. This ties the PIC32 reset pin to RTS on the UART. If RTS is high like it is on Windows, things work. Appearently the Mac pulls this low, or to a middle state and is enough to hold the MX7cK in reset when you activate the COM port from the Mac for uploading. We have reproduced and verified the fix on a Mac, so we know it is the problem. However, the ultimate discovery was by Gene's keen observation of the schematics.

To test this, you can remove JP11 and then hold the reset button down as MPIDE attemps to upload the scketch, as soon as MPIDE starts the upload, release the reset button. By removing JP11, you remove the ability for MPIDE to reset the board automatically, so that is why you have to do it yourself with the reset button. But make sure to release the reset button once MPIDE starts to upload.

To fix this, you can either remove the resistor yourself (which is pretty easy) or send the board back to Digilent and we will remove it for you.

Attached is a picture of where R159 is on the board (see pointer bottom right), just get out a soldering iron, and unsolder it, and pluck it off. Make sure you don't breach the connections with solder as that would just short it out. The resistor is super small, so you may lose it when it comes off.

[attachment=0]MX7cKR159.jpg[/attachment]

This is without a doubt our goof, a manufacturing error. We will be manually fixing every board in stock. But thank you for hanging in there with me until we found it.

Practically, this does not affect PC users, but only by luck. Be assured, every board that leaves the company will be fixed.

Sorry for your furstration, but there is a reason for everything; and finally we found it... And we would not have found it without your help.

KeithV

Wed, 08 Feb 2012 20:40:39 +0000

For anyone who owns an MX4cK.

During manufacturing R120 was unintentionally installed and may affect some users from successfully uploading a sketch from MPIDE, especially from a Mac; Windows appears to work, but only by luck.

Digilent is fixing this problem and no new boards shipped will have this resistor installed. You may fix this youself, or contact Digilent for repairs.

Below is a picture of the location of R120 and you can easily unsolder it from the board. We are very sorry for any inconvenience.

[attachment=0]MX4cKR120.jpg[/attachment]

KeithV

Wed, 08 Feb 2012 22:23:56 +0000

MX4cK and MX7cK users:

We have determined that the difference between Windows and the Mac with respect to the RTS signal is in how the FTDI drivers work. Realizing that the Linux driver is probably like the Mac one we have confirmed that Linux will suffer the same upload problem as the Mac. The solution for our Linux users is the same as for the Mac; and really the PC as well as that only works by luck. Remove the offending resistor.

lloyddean

Fri, 10 Feb 2012 17:34:20 +0000

Keith,

Might I suggest moving this thread overtop the one in chipKIT Boards where more people are likely to see it.

Also another minor issue. Of the four CEREBOT MX7 ck and four CEREBOT MX4 ck boards I now have all but one came with shorting blocks loose in the box. They all had to be replaced as defective as they wouldn't stay in place.

KeithV

Sat, 11 Feb 2012 16:37:17 +0000

Thanks Lloyd,

I will forward on the shorting block problem. I too have notice them being lose, but not as frequent as you. You can just bend the pins out slightly and they fit tighter.

I am going to let my boss handle the formal announcement of this fix. I assume by your response your boards are working now. Again, thank you for your help.

lloyddean

Sat, 11 Feb 2012 17:08:53 +0000

Thanks Lloyd, I will forward on the shorting block problem. I too have notice them being lose, but not as frequent as you. You can just bend the pins out slightly and they fit tighter. I am going to let my boss handle the formal announcement of this fix. I assume by your response your boards are working now. Again, thank you for your help.

Well, no, as they were ordered BEFORE the problem was isolated. An instructor I'm working with (no I'm not a student) has modified two boards at this point and I should have them in the next couple of days after which I'll get back to you.

For now I'd like to say thanks for sticking with this ...

donwills

Sat, 10 Nov 2012 08:38:58 +0000

FWIW, I encountered a problem with the exact same symptoms described here including what the messages look like when uploading with the SHIFT key pressed. Mac OS X. Latest version of all software, including Oracle Java 7. Cerebot MX7cK board from Digilent (Oct 2012) and there is no resistor in the place for R159.

Pressing reset while uploading got around the problem.

And then I figured out the jumper JP11 was off. Putting that jumper on and all worked fine!

jeremyb

Wed, 09 Oct 2013 10:25:03 +0000

Just received my new MX4cK and have experienced exactly the problem described here by Lloyd with being unable to upload from MPIDE on Mac OS.

My board has R120 in place which I gather has to be removed. Why is this still happening when the problem was apparently known about in Feb 2012?

Jeremy