Matrix user forums

More than a year ago I did a bit of work with CAN on the dsPIC33EP512GM710 and I had some issues with the speed configuration (see viewtopic.php?f=69&t=19843).
However I did get everything to work eventually.
Recently I began a new project using the same device which also needs CAN bus support, but I can't get it to work at all.
This lead me to go back to my first project to see where I was going wrong, and it 'appears' that some library file or similar update has stopped the CAN working.
If I use my original .hex file everything is fine, but when when I recompile it, the new .hex file is quite a bit smaller (26.6k rather than 28.7k) and the CAN appears to do nothing. No errors are produced during compilation.
The only thing I know that has changed in that time is that I have downloaded the 7.3 updates - unfortunately, I didn't have the foresight to back up the changed files first.
I have a feeling that it is possibly the PIC16BIT_CAL_CAN.c as I did once download the version given in this thread viewtopic.php?f=69&t=19898 and that stopped the CAN from working.

As per opening post, I can no longer produce working code from this CAN test program (dsPIC33_uart2can).

The original hex file (dsPIC33_uart2can.org.hex) works fine.
If I compile it now I get a smaller hex file (dsPIC33_uart2can.hex) that outputs nothing on the CAN bus (as observed on an oscilloscope).
I've messed about with it quite a bit using two host PCs and fresh Flowcode7 installation, but I can't get it to produce the working output.

Help! (please).

Regards,
Martin.

That does sound odd. Presumably the UART works, such that you know it's the CAN at fault?
I've attached a zip of older revisions of the PIC16BIT_CAL_CAN.c such that you can try them.
e.g. PIC16BIT_CAL_CAN@72.c is the oldest.

Hi Leigh,

Thanks for the archive:
@72 and @278 both work (albeit with the incorrect speed as per the thread referenced in my opening post).

All the others, including the as-installed version, appear to reset the device (i.e the whole PIC) when performing a buffer send.
Initially I couldn't understand what was happening, but I added a counter and delay into my data send loop before the CAN transmit - with the non-functioning CAL files the sent counter value is always 1.

Prog attached for reference.

Regards,
Martin.

Hi Martin,
Thanks for the information - I will look into it
Leigh

Hi Martin,
Could you please try the attached?
Thanks
Leigh

Hi Leigh,

Yes, that works - thank you.

If I add my post-init config (attached) as before, the speed is correct too @ 500kbps instead of 420.
Could a fix for that also be included?

Regards,
Martin.

So, here's an odd thing - depending on other code in the program, the transmitted CAN values may not be correct.
I've not really got to grips with the details yet, but if I have a simple loop that outputs an incrementing counter in the 8 CAN message bytes it works fine.
If I implement that same method in a larger program, the first two bytes are fixed values (in this case FC & 1F) but the other six count as expected.
There's quite a bit going on in the bigger program (several ADCs, PWMs and 2 SPI outputs) so I don't yet know if any specific component is responsible for this conflict/issue...

Following on from the above, the attached CAN test program (DSPIC33_CAN_work) produces the expected cycling output in all 8 bytes of the CAN message.
However, 'DSPIC33_CAN_fail' always outputs the first 2 bytes as 08 00 while the other six are correct.
The only difference between the two is the UINT variable 'knacker'. This variable is not actually used, merely defined.
Other variable types that I'm using (boolean, byte & byte array) don't seem to have this affect.

During testing the results vary depending on exactly what's defined, sometimes the leading two bytes might be different or the whole 8 bytes might be incorrect, but so far always seem to be a variation on a mix of 00, 08, 1F & FC.

Edited to add: This looks similar to what was happening in this thread?
http://matrixtsl.com/mmforums/viewtopic ... 8&start=25

Regards,
Martin.

I've not managed to resolve this yet.
Have you tried Flowcode V8 with this?
(As I've no hardware to test it on)

No, not tried that - I can give it a go though...

Hi Leigh,
On FC8 we're back to the device apparently resetting on a buffer send.
I tried the new CAN CAL file posted earlier, but that made no difference (are these files compatible between 7 & 8?)

Regards,
Martin.

Hi Martin,
Thanks for trying.
Yes, the two CAL files are the same at the moment (apart from a little header text)
The FC8 version goes here, which is usualy a hidden folder ...
C:\ProgramData\MatrixTSL\FlowcodeV8\CAL\PIC16BIT

Hi Leigh,

I'd put the CAL in the wrong place - Program Files(x86)/Flowcode v8/DefaultData.
Putting it in the ProgramData path makes the CAN work, but gives the same corrupted data as FC7.

Regards,
Martin.

Here's another variation that might be worth a try ...

Hi Leigh,

That gave the same results (CAN output but corrupted).

It also generated these warning messages during compile:
C:\Program Files (x86)\Flowcode 7\CAL\/PIC16BIT\PIC16BIT_CAL_CAN.c: In function 'FC_CAL_Internal_CAN_Init_1':
C:\Program Files (x86)\Flowcode 7\CAL\/PIC16BIT\PIC16BIT_CAL_CAN.c:350:16: warning: cast from pointer to integer of different size
C:\Program Files (x86)\Flowcode 7\CAL\/PIC16BIT\PIC16BIT_CAL_CAN.c:351:16: warning: cast from pointer to integer of different size
C:\Program Files (x86)\Flowcode 7\CAL\/PIC16BIT\PIC16BIT_CAL_CAN.c:366:16: warning: cast from pointer to integer of different size
C:\Program Files (x86)\Flowcode 7\CAL\/PIC16BIT\PIC16BIT_CAL_CAN.c:367:16: warning: cast from pointer to integer of different size

Regards,
Martin.

Any thoughts or updates on this issue?

Regards,
Martin.

Hi Martin,
I suspected a compiler or memory allocation issue, but investigations did not come up with any solutions.
I'm not that familiar with dsPIC.

Hi Leigh,

OK...
Any suggestions then?
Is there any mileage in, for example, trying to compile it in MPLABX?
I appreciate that you can't know every device, but it is supposed to be supported, and that makes it sound like you're just cutting it loose.

Regards,
Martin.

Hi Martin,
Yes, try anything.
Have you tried adding in more ints to see if it comes right again?
Maybe try without initialising the value of knacker?
We’ve tried memory alignment attributes on and off.
It’s odd that we have seen examples of MC/MU working without this issue, so it’s very peculiar.
I’ve read the compiler manual and the silicon errata sheet for this device and just don’t yet see any explanation.
I will have a chat with colleagues and see if we can get some hardware and more time to it

Hi Leigh,

OK, thanks for the suggestions (especially 'try anything' - LOL).
I'll try a few things and see what happens.
Definitely having different code produces different results in terms of how corrupted the output is - I'll have a play around with that.

Regards,
Martin.

It may also be worth downloading and installing the latest XC8 compiler. You can install it stand alone and then point Flowcode at it using the compiler options. It could be there is an error in the Flowcode packaged compiler for that specific device that is fixed in the latest version.

Yeah, that would be an alternative to using MPLABX to compile it.
Wouldn't it be XC16 for the device in question?

I've configured Flowcode to compile using XC16 V1.41, but that in itself did not make any difference.
Not initialising the variable also made no difference.
I will conduct further experiments...

I tried some of the other PIC_CAL_CAN.c files, and although that didn't fix the issue, it was interesting that the versions that previously caused a device reset do not do so with the later compiler.

Different variable configurations give varying results, but there's a definite pattern to the CAN output:

1x int/uint = 08 00 followed by 6 correct bytes
1x long/ulong = 00 00 and 6 correct
1x float = 2 correct then FC 1F 00 00 08 00
2x int = same as 1x long
3x int = FC 1F & 6 correct
4x int = same as 1x float