 |
 |
| View previous topic :: View next topic |
| Author |
Message |
SalihLabs
Joined: 27 May 2020
Posts: 8
Location: Ontario, Canada
|
| Dual core dsPIC33CH, Master core running, Slave core doesnt |
 Posted: Tue Jul 21, 2020 4:56 pm |
 |
|
Hi,
I am using the dsPIC33CH512MP508 with the example code "ex_ch_master.c" and "ex_ch_slave.c" files, slightly modified to match the clock and master/slave led pins. I am using PCWHD, version 5.093.
in ex_ch_master.c
Modified led pin
| Code: | | #define MASTER_LED_PIN PIN_E11 |
Modified #fuses
| Code: | | #fuses CPRE=0xFBFF // PIN_E10 controlled by Slave, all other PORTE pins controlled by Master |
Modified clock line:
| Code: | | #use delay(clock=100MHz, crystal=21335390, SLAVE: clock=200MHz, crystal=21335390) |
in ex_ch_slave.c
Modified led pin:
| Code: | | #define SLAVE_LED_PIN PIN_E10 |
Modified clock line:
| Code: | | #use delay(clock=200MHz, crystal=21335390) |
Modified ADC reading (don't care about the adc, just want to make sure MSI is functioning first):
| Code: | | Reading = 1; //read_adc(); |
The above are the only modifications to the example code.
I made sure to compile the slave code first, generate ex_ch_slave.hex, then compiled the master program, as the master program has to import the slave hex into the master hex during compilation.
Result:
The master LED is flashing, but the Slave led isn't.
Additionally, the serial monitor is only outputting the following:
| Quote: |
ex_ch_master.c - DSPIC33CH512MP508
Slave Program Verified
Slave Running
|
The slave is supposed to read from an adc, transfer the adc value over MSI mailbox to the master, and the master outputs the value over uart. However, nothing else is being outputted over uart after the "slave running" line, this tells me that the MSI communication isn't functioning, but since the slave LED isn't flashing, this tells me the slave core isn't running.
I also get a warning during compilation:
| Quote: | | line 111(0,1): Memory not available at requested location |
However, considering this is an example program, I'm not sure what to modify the memory start and end address to.
I would like to get the slave to start running, any help would be greatly appreciated. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Wed Jul 22, 2020 1:35 am |
|
|
A teeny 'smidgeon' puzzled by your clock settings.
Do you genuinely have a 21.33639MHz crystal?. Seems a very 'odd'
frequency. None of the standard manufacturers list this as an 'off the
shelf' frequency.
That having been said, looking through the code, I can see no reason
why it would not accept moving from E7 to E10.
First thought then:
Possibility that nobody at CCS has actually tested using the high byte
of PortE, and there is an issue with slave use of this?. Could you try using
another pin on the low part of this port, or on another port?. This would
at least allow this to be 'ruled out'.
Now, the memory error is 'interesting'. Happens with the examples
compiled as posted as well.
It is caused by the #org a couple of lines earlier. What is happening
is the code says 'reserve this area', then does the import into this
reserved space. The compiler at this point says "no memory at this location".
However it is a warning, not an error.
So try just remming out the
#org SLAVE_PROGRAM_START_ADDR,SLAVE_PROGRAM_END_ADDR {}
line. This then makes the error not happen, since the code can import
to these addresses, but may then result in the master overwriting this
area. I must admit, I would have expected the import to already be
reserving the area, so it will be interesting to see what effect this has.
If you look at the file produced when it generates the error, it does
correctly load the data anyway. So I suspect this is just a case that
the code really needs to disable this warning, and is not actually a
problem. |
|
|
SalihLabs
Joined: 27 May 2020
Posts: 8
Location: Ontario, Canada
|
|
| Posted: Wed Jul 22, 2020 7:15 am |
|
|
The crystal has 64MHz engraved on it, the timing was all wrong and UART was printing garbage. So I probed the crystal output and that was the frequency coming out of it (21.336Mhz), once I entered that in, the UART and Master LED flash rate started working. If you believe the non-standard crystal frequency has an effect on the slave core (but not master), I'll go ahead and solder a new crystal (one that outputs the same frequency as advertised).
I've soldered a bodge wire from PIN_E7 (example code slave LED pin) to the slave core LED. Note that I have not cut the pcb trace connecting PIN_E10 to the LED, E7 and E10 are effectively connected in parallel. I have updated the code to reflect the changes:
| Code: | | #define SLAVE_LED_PIN PIN_E7 |
| Code: | | #fuses CPRE=0xFF7F //PIN_E7 controlled by Slave, all other PORTE pins controlled by Master |
The master UART output is still the same (nothing after "slave running"), and the Slave LED isn't flashing.
I then commented out line 105 on ex_ch_master (#org), the compiler no longer gives a memory warning. Still no effect on Slave led and master UART. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Wed Jul 22, 2020 7:37 am |
|
|
Uurgh.....
The reason the crystal won't work, is it is way outside the maximum specified
for use with the PIC. Table 32-16. Maximum crystal frequency 40MHz....
Now this could well be causing major issues. Driving the oscillator
overfrequency, it'll lock onto sub-harmonics, and there is no guarantee
that the two PLL's will lock onto the same sub-harmonic. I'd say you
need to get a genuine crystal that is inside the range actually supported
by the PIC. You may well then find things start working....
Anything from 3.5MHz, to 40MHz. |
|
|
SalihLabs
Joined: 27 May 2020
Posts: 8
Location: Ontario, Canada
|
|
| Posted: Wed Jul 22, 2020 8:04 am |
|
|
You are correct! I have replaced the crystal with a 20MHz version (measured at 19.68 MHz), and the slave led is flashing and Master UART outputting the ADC reading from the MSI.
I am slightly confused as to why the maximum crystal frequency is 40MHz. Page 430 of the dsPIC33CH512MP508 datasheet (http://ww1.microchip.com/downloads/en/DeviceDoc/dsPIC33CH512MP508-Family-Data-Sheet-DS70005371D.pdf) states:
| Quote: | | External Clock Source Operation (EC Mode):If the on-chip oscillator is not used, the EC mode allows the internal oscillator to be bypassed. The device clocks are generated from an external source (0 MHz to up to 64 MHz) and input on the OSCI pin |
You mentioned table 32-16, there isn't one in the linked datasheet. What document are you looking at? |
|
|
gaugeguy
Joined: 05 Apr 2011
Posts: 303
|
|
| Posted: Wed Jul 22, 2020 9:12 am |
|
|
EC is external clock, an external clock module that outputs a square wave clock. This is not a crystal.
Crystal specs are in the paragraph above the one you quoted. |
|
|
SalihLabs
Joined: 27 May 2020
Posts: 8
Location: Ontario, Canada
|
|
| Posted: Wed Jul 22, 2020 9:17 am |
|
|
| Thanks for the clarification. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Wed Jul 22, 2020 11:18 am |
|
|
It's nice that we now know this demo does work. 
It is interesting to realise that the master PLL must have been getting
enough signal to work, while the slave one didn't.
Fun...
Oh, and the table number was from the datasheet on the MicroChip
site. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9228
Location: Greensville,Ontario
|
|
| Posted: Wed Jul 22, 2020 3:21 pm |
|
|
curious...
Is there some reason to have master and slave PICs running at very different speeds ??
I'm also thinking that at those speeds PCB layout, decoupling caps, etc. are CRITICAL to reliable operation. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19515
|
|
| Posted: Thu Jul 23, 2020 3:05 am |
|
|
The first is that they support different speeds. The Master core is a DsPIC
supporting up to 180MHz, while the slave core has slightly reduced abilities
but supports clocking up to 200Mhz. The idea is that the slave is optimised
for faster I/O. The slave does not implement instruction prefetch though,
having it's code loaded into RAM, instead of the ROM. This makes several
instructions in the slave core a lot faster than the master. So (for instance),
A DIV.SD (signed 32bit/16bit divide), takes 18 instruction times on the
master, but only 6 on the slave. So with both cores clocked to maximum,
0.2uSec on the master, but 0.06uSec on the slave!.... So over 3* faster.
Agree wholeheartedly on the layout... |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
