...I also tested my program on the dsPIC33CH Curiosity board and it behaves exactly the same as on my PCB design...
The other thread (about the CK device) went on and on (and on) after I reported success running at full speed (but I didn't give details)
It turned out that there were "issues" that I would never have run into because of the way I let MPLABX generate the configuration pragmas. (Or, using MCC for those projects.)
I have never had much satisfaction (or success) debugging other folks' hardware (layout, component selection, power, etc.) by remote control, so I (usually) don't even try.
Anyhow, since in the present thread it was reported that there are "issues" with the CH chip at full speed even with a Curiosity board, I decided to post a complete project that works for me at full speed.
I took the Microchip test program for the dsPIC33CH128MP508 with a few mods to illustrate running the Master Core at 90 MIPS and Slave Core at 100 MIPS on my Curiosity Board. (See Footnote.) Actually, I did this some time ago and passed along project files and notes to a few secret friends. It's, perhaps, a starting point for a "real" project.
Comments in main.c of each project give a description of the functionality.
Bottom line: Worked as I expected, based on the Data Sheet and the MCC setup for Master and Slave.
I used the external 8 MHZ clock on the Curiosity board.
UART ports are set to 115200 Baud by MCC.
LEDS are toggled with functionality defined by Master-Slave communications protocol, and cadence determined by __delay_ms()
based on FCY calculated from MCC-generated _XTAL_FREQ.
Output, using terminal emulator minicom, from PC USB port connected to Curiosity "USB-Uart" connector, J16:Master compiled on Aug 10 2019 at 14:28:30 by XC16 version 1036_XTAL_FREQ = 180000000, FCY = 90000000
Output from USB-to-Logic converter connected to RD0 and RD1 at the mikroBUS A port (J3):Slave compiled on Aug 10 2019 at 14:28:18 by XC16 version 1036_XTAL_FREQ = 200000000, FCY = 100000000
(MPLABX version 5.15, MCC plug-in 3.75, XC16 version 1.36B)
Debugging with the Curiosity's PKOB would be a real pain since it won't let me set breakpoints while running. I mean, I was able to set a breakpoint in the Master main()
function and single-step through some sequences, but since I would have to re-compile each time I want to change the breakpoint location, it's easier (especially for an old-school curmudgeon like me) to just sprinkle printf()
around the landscape to verify proper operation during step-at-a-time development. (See Footnote.) My point is that it works for me.
I don't usually post full code for projects, but after enduring the other agonizing thread, I'll break with personal tradition.
Bottom line suggestion:
The forum won't let me post .zip files, so I tacked on .txt in order to attach the packaged files. Rename them to be .zip (without the .txt) Put .zip files in some convenient MPLABX project directory (nnote: be sure to put them in the same
directory) and unzip them. You get two projects, named Master and Slave. If your I/O connections are different, make changes in the source files (or, perhaps it would be better to let MCC do it for you). If the Microchip tutorial is not completely adequate for your purposes, follow instructions in one of the many tutorials that are floating around.
This demo project is for a PIM, but I/O is compatible with the Curiosity board:https://microchipdevelope...-for-dual-core-devices
First I read through the entire tutorial, and I got things running exactly as described. (Huzzah!) I used MPLABX "package" function to make sure I had a fall-back position to something that works. I package the projects whenever I make significant changes. (The history function of the MPLABX editor lets you back out of text changes in source files, but the biggest headache for many folks is undoing changes in the MCC setup.)
Then, using MCC, I made clock changes in both projects to get their cores running at max speed from the external 8 MHz clock input, and I added UARTs. It's not really all that tough if you have read through the tutorial. I don't recommend a "fiddle-fart-around-until-you-get-lucky approach. Ars longa, vita brevis!
Finally I changed the logic in the main() functions as described in the comments in the main.c files.
post edited by davekw7x - 2019/08/10 16:51:49