I have been using dsPIC33EP32GP502 (32KB version) with the CAN BUS component flawlessly so far. We integrate on the same chip / FC8 program: I2C, SPI, Serial1, Serial2 (Bluetooth), SPI APA102 LEDS and CAN bus with no issues at all.
But now we have a new target dsPIC33EP256GP502 (same MCU series just with 256KB of ROM and more RAM).
When we enable/initialize the CAN Bus component, whatever we do after that, for example reading an input or using an output (input/output pin), the MCU resets itself We have other components in the program and it works fine, it's an OLED SPI buffered display.
We have tried on both internal FRC, FRC + PLL, external crystal HS and HS + PLL without luck, so this looks to be related to Flowcode...
Many thanks for your help with this problem!!
I've just compared the Flowcode definition files for the two devices and can't see anything specific which looks out of place here.
Do you get any warnings when you compile to hex?
It might be worth trying with a newer version of the XC16 compiler to see if it's a compiler bug causing the problem.
Yes some warnings
Code: Select all
Device: PIC16.33E.33EP256GP502 Generated by: Flowcode v184.108.40.206 Date: Monday, June 17, 2019 11:14:55 Users: 1 Registered to: License key: ***** https://www.matrixtsl.com Launching the compiler... C:\Program Files (x86)\Flowcode\Common\Compilers\pic16\batchfiles\pic16_C30_comp.bat "PIC3_OLED_MENU_FRC_121MHZ_256KB_TEST_BASE" "D:\Projects\CASHAR~1\Products\ELECTR~1\U22BEL~1\FC8\PIC3_O~1\" "33EP256GP502" D:\Projects\CASHAR~1\Products\ELECTR~1\U22BEL~1\FC8\PIC3_O~1>xc16-gcc -c -mcpu="33EP256GP502" -omf=coff -funsigned-char -fno-short-double -Os -I"C:\PROGRA~2\Flowcode\Common\COMPIL~1\pic16\BATCHF~1\..\support\h" -I"C:\PROGRA~2\Flowcode\Common\COMPIL~1\pic16\BATCHF~1\" -std=gnu99 "PIC3_OLED_MENU_FRC_121MHZ_256KB_TEST_BASE".c -o "PIC3_OLED_MENU_FRC_121MHZ_256KB_TEST_BASE".o Options have been disabled due to restricted license Visit http://www.microchip.com/ to purchase a new key. PIC3_OLED_MENU_FRC_121MHZ_256KB_TEST_BASE.c:1561:1: warning: '_FICD' definition has been deprecated: consider migrating to #pragma config PIC3_OLED_MENU_FRC_121MHZ_256KB_TEST_BASE.c:1561:1: warning: '_FPOR' definition has been deprecated: consider migrating to #pragma config PIC3_OLED_MENU_FRC_121MHZ_256KB_TEST_BASE.c:1561:1: warning: '_FWDT' definition has been deprecated: consider migrating to #pragma config PIC3_OLED_MENU_FRC_121MHZ_256KB_TEST_BASE.c:1561:1: warning: '_FOSC' definition has been deprecated: consider migrating to #pragma config PIC3_OLED_MENU_FRC_121MHZ_256KB_TEST_BASE.c:1561:1: warning: '_FOSCSEL' definition has been deprecated: consider migrating to #pragma config PIC3_OLED_MENU_FRC_121MHZ_256KB_TEST_BASE.c:1561:1: warning: '_FGS' definition has been deprecated: consider migrating to #pragma config Compilation successful!
Directory of C:\Program Files (x86)\Flowcode\Common\Compilers\pic16\batchfiles
04/05/2018 18:16 516 pic16_C30_comp.bat
04/05/2018 18:16 549 pic16_C30_compLarge.bat
06/02/2018 13:19 1,582 pic16_C30_link.bat
06/02/2018 13:19 1,660 pic16_C30_linkLarge.bat
22/05/2019 15:53 1,582 pic16_C30_link_ben.bat
Is this supposed to be used instead of the normal batch file for this MCU?
It's probably worth trying the large version of the compiler and linker using the compiler options to see if this makes a difference.
Let us know how you get on.
Thanks for the swift reply... All right, have done some debugging on my end... from FC8.
I have tried the latest Microchip's XC16 gcc compiler without luck, same results. Also with the pic16_C30_compLarge.bat instead, same problem.
Enabling the CAN Bus component (internal) alone doesn't produce any problems.
But when i send the buffer (SendBuffer) command, the MCU resets itself.
If I change the CAN Bus component from internal to external (SPI Software or Harware) and connect the PINS to unused pins of the MCU, then the program takes a long time to start (like 15seconds), but it does not reset....
If you can point out where I can do ICD3 debugiing (a guide), I can def. ru this alongside the code to find the culprit). This if you find it's a good idea... I can see what the program is really doing on hardware just before it reboots?
On the FC below, the culprit is SendBuffer... the previous 2 commands SetTXIdent and SetTXData don't cause the reset... There is def. something going on with the CAN Bus component and this device. I have tried buffers 0, 1 and 2 with same results Settings the
Thanks for your help!
Any more ideas here? I tihnk I found what the problem is.. the 2 chips we use are of the same series dsPIC33EP32GP502 (32KB ROM) and dsPIC33EP256GP502 (256KB) have got different options in Flowcode when they should have the SAME ones:
The differnet flag is PWMLOCK .
On dsPIC33EPXXXMC20X/50X and PIC24EPXXXMC20X devices, write protection is implemented for the IOCONx and FCLCONx registers.... The write protection feature prevents any inadvertent writes to these registers. This protection feature can be controlled by the PWMLOCK Configuration bit (FOSCSEL<6>). The default state of the write protection feature is enabled (PWMLOCK = 1 ). The write protection feature can be disabled by configuring, PWMLOCK = 0 .
It seems this flag has nothing to do with our MCU... Our device is NEITHER dsPIC33EPXXXMC20X/50X NOR PIC24EPXXXMC20X .
It's dsPIC33EP256GP502. So this means there is definitely an issue with the FC8 configure bits...
Coudl you please have a look?
- Valued Contributor
- Posts: 1937
- Joined: Wed Aug 27, 2008 10:31 pm
- Location: Netherlands
― C.S. Lewis
The problem here is that the config bits in FC8 for dsPIC33EP256GP502 (general purpose) are wrong (PWMLOCK shouldn't even be on the list at all), who knows what else is wrong here. FC8 assumes that the device is an MC device and not a GP one as it should be...
I will try to edit the C generated code to see if I get it to at least not reset... and reprt back
Thanks for your help,
Code: Select all
... #include "p33Exxxx.h" //Configuration Start _FICD(65484); _FPOR(65535); _FWDT(65407); _FOSC(65471); _FOSCSEL(65337); _FGS(65535); //Configuration End ...
Code: Select all
PWMLOCK (1) 1: This bit is only available on dsPIC33EPXXXMC20X/50X and PIC24EPXXXMC20X devices.
One fo the many I have tried
Code: Select all
FOSCSELbits.PWMLOCK = 0;
Code: Select all
... PIC3_OLED_MENU_FRC_121MHZ_256KB_TEST_BASE.c: In function 'main': PIC3_OLED_MENU_FRC_121MHZ_256KB_TEST_BASE.c:1516:2: error: 'FOSCSELbits' undeclared (first use in this function) PIC3_OLED_MENU_FRC_121MHZ_256KB_TEST_BASE.c:1516:2: note: each undeclared identifier is reported only once for each function it appears in Error returned from [xc16-gcc.exe] ...
Any further news on this one?
We will buy 64KB and 128KB versions of these MCUs asap at least to try them out and see if they reset at all with the same code... If either work, then we can use those.... unfortunately the CAN bus is essential part of our system... We need more running code space on this specific module as its controlling an LCD + CAN bus and the 32KB we use for all other modules is not enough, initially we needed a simple menu, but the requirement had changed and we ended up having to display bitmaps and so on... ther eis little difference in price between 64KB/128KB/256KB MCUs.
If you need me to debug something on my end on hardware, I am more than open to do that.
I've tried 128KB version of this chip dsPIC33EP128GP502 and it does not reset when CAN SendBuffer() function is called, need to do more testing, but seems for now that this MCU works with Flowcode. 128KB of ROM is more than enough for our program, so if all goes well then we will forget about 256KB version, altough we had bought 30qty of them...
Let me do more tests and get back to you with results.
OK this 128KB MCU dsPIC33EP128GP502 works for now. We only run GLCD SSD1306 Buffered + CAN BUS + Input buttons and it does the job and does not reset any more even wth more complex code than before.
Happy we found a solution for this one in the end.
Brilliant thanks for letting us know. I wonder if there is a silicone errata document for the 256 device i.e. a known problem.
The same code should run fine on both and generally a family will share a silicone design so strange the 128 version is ok but the 256 is not?
I'll make a note in case we run into the problem again.
I understand and had checked the errata for these chips and couldn't find anything relevant...
If you want, I can send you some of these 256KB MCUs, just in case if you needed them, we use the 28-pin SSOP ones, let us know.
Cheers again and keep up the great work!
PS: I am not a forum nor social media guy, however would be nice to have a dedicated page on your website where people can show their working projects with Flowcode...? I have to thank the Flowcode team for this great product that makes programming MCUs (especially Microchip ones) a breeze. Writing in C gets very very tricky if you don't have (like myself) the programmers mindset... also it's so easy with Flowcode to optimize things just by moving things around / creating subprograms, especailly when designing GUIs... I can concentrate more on the user experience than the programming