Wrong connection of CANport on eMEGA

[KeesZagers]

I believe the eMEGA has a hardware design error concerning the connection of the CANbus. The schematics shows CAN Tx and CAN Rx on pins 7 and 8 of the PIC controller, however in my opinion they are on the pins 88 and 87. These pins are also used for the Ethernet controller ETXD0 and ETXD1. These pins are directly connected to Ethernet controllerchip.

Anyway the CAN 1 port cannot be activated in software, probably caused by a wrong voltage level forced by the ethernet controller. Anyway I dont't believe I will see any CAN activity on the CAN connector of the eMEGA anyway.

Allthough I have not tested it yet, probably the CAN 2 port will work. This port is connected to the D8 and D9 pins of the Arduino connector and for this port the addition of a CAN transceiverchip (MCP2551) is needed.

Can anyone of Olimex or someone else who has done anything with CAN on the eMEGA correct me if I'm wrong.

Kees

[JohnS]

I don't know why, but it looks like they put the CAN1TX/RX to the AC2TX/RX pins i.e. if you config for the Alternate CAN then the chip's CAN2 port will activate via the board's CAN1TX/RX.

Alternate CAN is in DEVCFG3, bit 26 (FCANIO).

If it works you'll be able to use the on-board MCP2551

John

[KeesZagers]

Thanks John,

I was not aware of the fact that AC stands for Alternate CAN. And I must say that Microchip seems to have made a good kept secret of it. If I google on it, it seems that I'm not the only one who has problems with it.

Anyway I'm gonna try to modify the existing firmware for the MEGA to let it work also on the eMEGA by changing the DEVCFG3 and also swap the CAN 1 and CAN 2 ports.

Kees

[JohnS]

I hope you get it working - there IS interest out there, and always will be

John

[KeesZagers]

I think I have to give up now and remain at the second option to use the CAN 2 port only with an extra CAN transceiver chip on the Arduino extension.

The problem with modifying the DEVCFG registers, is that you have to do this at the very beginning. Logically ofcourse because you are configuring hardware settings.

However my only possibility to change code is in the DMBASIC sources and before the main.c of DMBASIC is executed, the processor already executed the bootloader code.

The eMEGA bootloader seems not to have implemented the FCANIO change, so it stops for me here. Ruuning DMBASIC without bootloader would be too complex for our users, because in that case updates cannot be easy implemented anymore.

[JohnS]

Can't you just change that one bit in the bootloader?  (E.g. in its HEX then reflash.)

John

[KeesZagers]

I really would not know where to find it. I don't know if the bootloader is available in source anywhere. As far as I have seen only the HEX file is on github.

Kees

[JohnS]

Aha - DEVCFG3 is at almost the last word (actually DEVCFG0 is the last word, they go backwards, oddly) of the boot area (for any PIC32).  The data sheet gives its address.  You'll also see it in linker scripts (such as .ld files).  The 795's is 0xBFC02FF0

HEX files typically have a record setting the high address, which is understood to continue for subsequent records.  So you tend to see a record setting 0xBFC0 (maybe with the bottom 0000 omitted).

Later you'll find a record with address 2FF0 and the first 4 bytes will be DEVCFG3.

Oh, but if left at its default then it won't be there at all.  Remind me which one you use on github and I'll have a look.

John

[KeesZagers]

Thanks again for your assistance, John.

The HEX bootloader I used is the one on the Olimex site, I believe, referred to at the eMEGA pages:

https://www.olimex.com/Products/Duino/Duinomite/_resources/Olimex_s_Duinomite_HIDBootloader.zip

I must admit I did not compare it with the one which is on GITHUB, which has recently been changed from location I have seen. Now:

https://github.com/OLIMEX/DuinoMite/blob/master/SOFTWARE/FIRMWARE/DuinoMite-eMega_ONLY_Bootloader.hex

They seem to be quite different. Now I'm doubting if I have the correct one. I have changed the default pre-installed one when I was experimenting with MPIDE.

Maybe you can look at both of them, I will do some experimenting later, but in that case I have to make a setup with the PIC-KIT3 again, which is not up and running now.

Kees

[JohnS]

I'll take a look but it'll be in a few days time - sorry for the wait!

You could flash any board without a PICkit, e.g. using another PIC32 board or an Arduino-type board or even an RPi if that would be useful.

John

[KeesZagers]

No problem to wait a few days.

However you are confusing me with your remark about the flashng. Ofcourse I can reflash the firmware, but if I want to change the bootloader, I have to use the PIC-KIT3 hardware to remove the old bootloader and install the new one. At least I was told so when I replaced the bootloader by the chipkit bootloader to get MPIDE running on the Duinomites.

Kees

[KeesZagers]

I believe all problems are solved now.

1. I tested both versions of the bootloader now using my PIC-KIT3. The two versions are acting different. The one on GITHUB seems to be the right one, because this one flashes both green and yellow LED when USER-RESET is pressed. The other one, referred to on all the dynomite WEBpages under DMBasic, flashed only the green LED and I believe this one is the chipkit bootloader for MPIDE. So I continued with the GITHUB version.

2. I checked the DMBasic sources on Configuration Bits.h. Here I found following entry:

#if defined(__32MX795F512H__)
#pragma config FCANIO = ON            // CAN IO Pins. OFF = Alternate, ON = Default
#endif

As the eMEGA is the only one using the L version of the chip, I included the follwing entry:

#if defined(__32MX795F512L__)
#pragma config FCANIO = OFF            // CAN IO Pins. OFF = Alternate, ON = Default
#endif

When I compiled the DMBasic I could see the alternate CAN configuration in MPLAB-X Window -> PIC Memory Views -> Configuration Bits. However in runtime nothing had changed the DEVCFG3 had FCANIO still on DEFAULT. After googling other people with problems it became clear to me that the combination of bootloader and application software resulted in only the first call: so the bootloader. The changes in DMBasic have no effect.

3. Thanks to John I dived into the HEX-files and indeed this worked out fine.

The edited DMBasic, with the right FCANIO configuration, first 3 lines:

:020000040000fa
:020000041fc01b
:042ff000ffff07a236

And the bootloader first 3 lines:

:020000040000fa
:020000041fc01b
:042ff000ffff07a632

Remark for John: Don't look for BFC0, but for 1FC0 (absolute address, not the virtual one)

The difference is in line 3: A2 stands for alternate CAN; A6 for default. (the difference 32 vs 36 is the checksum of the line).

So I replaced the 3rd line in the bootloader by :042ff000ffff07a236. Reflashed the bootloader again with the PIC-KIT3. Flashed DMBasic in the normal way and everything seems to work fine now.

So for Olimex:
1. Check the bootloader links on your WEBsite. It is not compatible with the one on GITHUB.
2. Maybe update the DMBasic for eMEGA, however it does not make sense if a bootloader is included.
3. Edit the bootloader (maybe only the HEX, as I did) for the eMEGA.

Kees

[JohnS]

Excellent! And yes I did mean 1FC0.  Sorry.

You have it correct, that's great.

About flashing without a PICKit I just meant that in case it's easier not to use one (maybe in the field or to avoid buying multiple PICkits or some such), it's possible to program any PIC32 using just about any other uC (or even via a PC).

As you have a PICki3 it may well be you're happy to go on using it.  In case that's not so, just say as it can be avoided.  (I find it easier to use a Rasp Pi or even a USBASP.)

John

[KeesZagers]

OK, the problem is solved now and I can communicate on the second alternate CAN port. The first one cannot be used, because it is only connected onboard to the RS232 port. So I will make the software available for the eMEGA, but only support for one CAN port.

Important for all users of the eMEGA that want to use the CANport. You have to change the bootloader and you have to communicate on CAN2.

Thanks again John for our advises.

Kees

[JohnS]

Hey - it's great to hear it works!

You're very welcome - it's you that's done the real work

John