| View previous topic :: View next topic |
| Author |
Message |
umarkhan
Joined: 09 Dec 2014
Posts: 7
|
| How to run dspic33ep256mu806 at maximum MIPS? |
 Posted: Tue Jan 06, 2015 6:04 am |
 |
|
hello,
I am currently using a dspic33ep256mu806 and wish to run it at the maximum speeds mentioned in the data sheet which vary between 60-70 MIPS. I do not know if I am testing it in the correct way, but I have written a simple code the uses an output_high command followed immediately by an output_low command in a while loop. I expect a pulse at the corresponding output pin to be about 14-16 ns. In addition I have used
a) the #use delay directive to set the clock to 120M using the PLL.
b) the #use fast_io directive to minimize the resulting assembly code.
My final code is as follows,
| Code: |
//includes
#include <33EP256MU806.h>
#fuses PR_PLL
#fuses PLLWAIT
#FUSES CKSFSM //Clock Switching is enabled, fail Safe clock monitor is enabled
#FUSES NOBROWNOUT //No brownout reset
#use delay(clock=120M, xtal=8M)
void main()
{
output_high(28821);
while(1)
{
#use fast_io(B)
output_high(28821);
output_low(28821);
delay_us(100);
}
}
|
I get the following trace on the output pin which is about 40ns 
post images
any pointers will be welcome,
Umar. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Tue Jan 06, 2015 8:46 am |
|
|
It's more like 33nSec. Look at where the signal starts to move.
Exactly half what you'd expect.
What compiler version?.
If you look at the code, it generates:
| Code: |
.................... output_high(28821);
0021E: BSET.B E14.5
.................... output_low(28821);
00220: BCLR.B E14.5
|
I don't like the coding style at all. Use the pin names, not numbers that can go wrong, and remember that #use fast_io, is not a line of code, but a pre-processor directive. However these don't stop it working.
Are you sure your crystal is working, and at 8MHz?.
What happens if you try with the internal oscillator?.
The current compilers correctly sets CLKDIV to 0, and PLLFBD to 0x3A, which for 8Mhz in, gives:
Fosc = 8MHz * (0x3A+2)/(2+2) = 120MHz. So this is correct. |
|
|
umarkhan
Joined: 09 Dec 2014
Posts: 7
|
|
| Posted: Tue Jan 06, 2015 10:43 am |
|
|
hi,
The compiler version is 4.130. I was originally using the #define to assign a name to the pin, but then thought that directly addressing the pin number might be a little faster. I use names for pins and will revert to the original method for later posts.
I tried using the internal oscillator using
#use delay(clock=120M, internal)
but this makes no difference. I checked the crystal and it correctly generates the 8M signal.
I suspect my compiler does not write to the CLKDIV and PLLFBD registers. This is because when I open the generated hex file in ccs I don't see the addresses 0x0744 and 0x0746 (CLKDIV and PLLFBD) any where, but do see the 0xF0006 and 0xF0008 addresses which correspond to the FOSCEL and FOSC.
Is there any way I can write directly to the CLKDIV and PLLFBD? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Tue Jan 06, 2015 11:42 am |
|
|
Yes, I'd definitely suspect compiler version. That is an old compiler for that chip.
You can simply declare the registers with a #word, and write to these, but you have to generate the unlock sequence first. Get the reference manual 70268A, and look at the section entitled 'clock switching'.
I think code to do this using #ASM was posted here at the time that your compiler dates from. A forum search should find it. Possibly by Ckielstra, or Temtronic?.
Have a look at this thread:
<http://www.ccsinfo.com/forum/viewtopic.php?t=49419&highlight=dspic33+clock>
I was going to say it is probably easier to wake up using FRC, program the PLL, and then switch, which is what he does. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Wed Jan 07, 2015 3:41 am |
|
|
Just an update. Checked 'old compilers', and a couple of versions earlier, this PIC is not present. 4.130, is one of the very earliest supporting the chip. Common for there to be problems for a few versions after a chip is added...
Half a dozen versions later, it is setting the clock up correctly. |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Wed Jan 07, 2015 4:45 pm |
|
|
| Ttelmah wrote: | Just an update. Checked 'old compilers', and a couple of versions earlier, this PIC is not present. 4.130, is one of the very earliest supporting the chip. Common for there to be problems for a few versions after a chip is added...
Half a dozen versions later, it is setting the clock up correctly. |
Last v4 was 4.141
Unless he want to jump the v5 bandwagon (which I did)
I remember the transition few years ago, V3 to V4 compiler was brutal ( and buggy )...
V3 was good until around V4.060
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1909
|
|
| Posted: Wed Jan 07, 2015 7:26 pm |
|
|
| ELCouz wrote: | | Ttelmah wrote: | Just an update. Checked 'old compilers', and a couple of versions earlier, this PIC is not present. 4.130, is one of the very earliest supporting the chip. Common for there to be problems for a few versions after a chip is added...
Half a dozen versions later, it is setting the clock up correctly. |
Last v4 was 4.141
Unless he want to jump the v5 bandwagon (which I did)
I remember the transition few years ago, V3 to V4 compiler was brutal ( and buggy )...
V3 was good until around V4.060 |
I'm still not brave enough to try v5. Not worth the headache (in my evaluation) yet....until I find a chip that 4.141 doesn't support at all. Not that it supports the dsPIC I am using, but I have my code working absolutely flawlessly and I'm not going to risk inducing any funny things by upgrading to v5. |
|
|
umarkhan
Joined: 09 Dec 2014
Posts: 7
|
| compiler test |
| Posted: Thu Jan 08, 2015 9:56 am |
|
|
hi Ttelmah,
We are investigating the possibility of an upgrade to the latest compiler, but we need to know if the latest compiler will actually solve the problem. As you mentioned that the latest compiler sets the CLKDIV and PLLFB registers correctly, would it be possible for you to send me the hex file compiled for the code i posted earlier by the latest compiler. If it works this would be very helpful in securing a purchase 
Umar |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9243
Location: Greensville,Ontario
|
|
| Posted: Thu Jan 08, 2015 10:24 am |
|
|
something to consider...
be sure to design the PCB for the speed !! you need proper layout,size of traces,bypass caps,smooth power,etc. to get any micro to run that fast and be reliable.
No amount of software will fix a faulty hardware design.
just food for thought.
Jay |
|
|
oxo
Joined: 13 Nov 2012
Posts: 219
Location: France
|
|
| Posted: Fri Jan 09, 2015 7:25 am |
|
|
| OP, I'm using the same part, but it's not connecting. Are you using ICD-U64? |
|
|
oxo
Joined: 13 Nov 2012
Posts: 219
Location: France
|
|
| Posted: Mon Jan 12, 2015 12:08 am |
|
|
| oxo wrote: | | OP, I'm using the same part, but it's not connecting. Are you using ICD-U64? |
I should say its not connecting using PGEC1 and PGED1. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Mon Jan 12, 2015 1:27 am |
|
|
| You are aware you need a revision 3 ICD-U64, to debug these chips?. Your existing unit can be modified to this revision. |
|
|
oxo
Joined: 13 Nov 2012
Posts: 219
Location: France
|
|
| Posted: Mon Jan 12, 2015 1:35 am |
|
|
| Ttelmah wrote: | | You are aware you need a revision 3 ICD-U64, to debug these chips?. Your existing unit can be modified to this revision. |
Yes,
I had that issue a couple of weeks ago with the Explorer16.
What I have is my code running on the Explorer, but when I go to my own hardware it won't program.
The biggest difference is that the explorer uses a 33EP512MU810.
As always, it will be some stupid thing I missed.. probably.
I am trying the OPs code above and that won't program either.
PCWHD V 5.036
dsPIC33EP256MU806 |
|
|
oxo
Joined: 13 Nov 2012
Posts: 219
Location: France
|
|
| Posted: Mon Jan 12, 2015 1:49 am |
|
|
 |
|
|
Eugeneo
Joined: 30 Aug 2005
Posts: 155
Location: Calgary, AB
|
|
| Posted: Mon Jan 12, 2015 2:14 am |
|
|
I can't test it since I don't have this particular chip, but it seems to be all there.
| Code: |
CCS PCD C Compiler, Version 5.036, 14388 12-Jan-15 01:10
Filename: C:\Micro\main.lst
ROM used: 556 bytes (0%)
Largest free fragment is 65536
RAM used: 128 (0%) at main() level
129 (0%) worst case
Stack used: 0 locations
Stack size: 128
*
00000: GOTO 200
.................... #device DSPIC33EP256MU806
....................
.................... #list
....................
....................
.................... #fuses PR_PLL
.................... #fuses PLLWAIT
.................... #FUSES CKSFSM //Clock Switching is enabled, fail Safe clock monitor is enabled
.................... #FUSES NOBROWNOUT //No brownout reset
....................
.................... #use delay(clock=120M, xtal=8M)
....................
.................... void main()
*
00200: MOV #7F80,W15
00202: MOV #7FFF,W0
00204: MOV W0,20
00206: NOP
00208: BSET.B 8C1.7
0020A: CLR 744
0020C: MOV #3A,W4
0020E: MOV W4,746
00210: CLR E1E
00212: CLR E2E
00214: CLR E3E
00216: CLR E4E
00218: CLR E6E
.................... {
.................... output_high(28821);
0021A: BCLR.B E10.5
0021C: BSET.B E14.5
....................
.................... while(1)
.................... {
.................... #use fast_io(B)
.................... output_high(28821);
0021E: BSET.B E14.5
.................... output_low(28821);
00220: BCLR.B E14.5
.................... delay_us(100);
00222: REPEAT #176E
00224: NOP
00226: GOTO 21E
.................... }
....................
.................... }
0022A: PWRSAV #0
|
|
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
