 |
 |
| View previous topic :: View next topic |
| Author |
Message |
quadro
Joined: 09 Feb 2012
Posts: 4
|
| dsPic33ep DMA register address wrong? |
 Posted: Wed Feb 20, 2013 5:26 pm |
 |
|
Hi friends, I'm sorry for my bad english.
I'm using dspic33ep64mc204 and I'm trying DMA from SPI communication.
When I looking list file DMA SFR address is wrong. For example: my dspics DMA0CON address 0x0b00
DMA0STAL address 0x0b04
DMA0STBL address 0x0b08
My list file address very different (when you looking setup_dma(), dma_start() address likes 0x380,0x381,0x388) Why different?
Thanks for answers.
my listfile here
| Code: |
.............................. setup_spi2(SPI_SLAVE | SPI_L_TO_H | SPI_CLK_DIV_64);
07A6: BCLR.B 261.7 : SPI2STAT.SPIEN = 0
07A8: BCLR.B 260.6 : SPI2STAT.SPIROV = 0
07AA: MOV #9C,W4 : W4 = 9C
07AC: MOV W4,262 : SPI2CON1 = W4
07AE: BSET.B 261.7 : SPI2STAT.SPIEN = 1
.............................. setup_dma(0, DMA_IN_SPI2 , DMA_BYTE);
07B0: MOV.B #40,W0L : W0L = 40
07B2: MOV.B W0L,381 : [381H] = W0L
07B4: MOV.B #21,W0L : W0L = 21
07B6: MOV.B W0L,382 : [382L] = W0L
07B8: MOV #268,W4 : W4 = 268
07BA: MOV W4,388 : [388] = W4
.............................. dma_start(0, DMA_CONTINOUS, &DMA_SPI2_RECEIVED_BUFFER_CH0[0] );
07BC: BCLR.B 381.7 : [381.7] = 0
07BE: CLR.B 380 : [380L] = 0
07C0: MOV #101E,W4 : W4 = 101E
07C2: MOV W4,384 : [384] = W4
07C4: MOV #3,W4 : W4 = 3
07C6: MOV W4,38A : [38A] = W4
07C8: BSET.B 381.7 : [381.7] = 1 |
|
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19383
|
|
| Posted: Thu Feb 21, 2013 1:38 am |
|
|
Repeat three times. Compiler version?.....
Best Wishes |
|
|
quadro
Joined: 09 Feb 2012
Posts: 4
|
|
| Posted: Thu Feb 21, 2013 3:05 am |
|
|
| Ttelmah wrote: | Repeat three times. Compiler version?.....
Best Wishes |
my compiler version 4.130
Let me repeat 3 times Why? (is it my spi dma reading 3 bytes?)
Thanks.. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19383
|
|
| Posted: Thu Feb 21, 2013 3:42 am |
|
|
Why?.
Because the chip database changes with just about every compiler, and especially on recently supported chips is commonly full of errors like this.
Hence in the 'forum guidelines', you have as things that should be included with a question:
| Quote: |
Version of your compiler
Target PIC Microcontroller (PIC16F877, 18F452, etc)
Standard Run Mode or Debug Mode
Target voltage (5V, 3.3V, etc)
Target oscillator speed, type (20Mhz, RC, Strip Cut, etc)
Any relevant C or ASM source code
|
Weirdly (a CCS stupidity), the database used by the compiler for it's code, is _not_ the one reported using the 'registers' option. So you will find that a particular compiler version can report a register at one address, and use a completely different one itself. Hence the only way we can help at all, is by knowing the compiler version, compiling your code, looking and seeing if the results are the same for us, and then either giving a 'manual fix', or informing you that a later compiler fixes it.
Best Wishes |
|
|
quadro
Joined: 09 Feb 2012
Posts: 4
|
|
| Posted: Thu Feb 21, 2013 4:26 am |
|
|
| Ttelmah wrote: | Why?.
Because the chip database changes with just about every compiler, and especially on recently supported chips is commonly full of errors like this.
Hence in the 'forum guidelines', you have as things that should be included with a question:
| Quote: |
Version of your compiler
Target PIC Microcontroller (PIC16F877, 18F452, etc)
Standard Run Mode or Debug Mode
Target voltage (5V, 3.3V, etc)
Target oscillator speed, type (20Mhz, RC, Strip Cut, etc)
Any relevant C or ASM source code
|
Weirdly (a CCS stupidity), the database used by the compiler for it's code, is _not_ the one reported using the 'registers' option. So you will find that a particular compiler version can report a register at one address, and use a completely different one itself. Hence the only way we can help at all, is by knowing the compiler version, compiling your code, looking and seeing if the results are the same for us, and then either giving a 'manual fix', or informing you that a later compiler fixes it.
Best Wishes |
Forum rules I'm sorry. One more question, will be better. I think I'm gonna definition file manually.
Thanks for your answer. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1903
|
|
| Posted: Thu Feb 21, 2013 10:21 am |
|
|
| Working through several projects using a dsPIC33FJ256GP710 and for the first time ever I've had to manually set registers myself instead of relying on CCS' built-in functions. Between the compiler referring to wrong register addresses, wrong settings of said registers, and plain old compiler bugs, my only option was to go full manual on things like setting up timers, CAN, CN registers, etc. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1329
|
|
| Posted: Thu Feb 21, 2013 6:31 pm |
|
|
Ive been using the dsPIC33FJ256GP710A lately, but haven't run into those type of issues. So far all the registers related to the peripherals I used have been good. Granted, I am just using A/D, SPI, UART, external interrupts, and timers, so I am not working on anything complex (also 4.140 compiler if that makes a difference)
My guess is a lot of these chips aren't used as much by people on the forums here, so errors go longer without being detected. And, even if people do detect them, they still don't always report them to CCS support. If the chip the OP is using is relatively new (with respect to CCS chip support), I could see it having a lot of register issues.
In reference to the OP's chip, they did make improvements to DMA on the EP chips in 4.136 and I think another update as well. It might be worthwhile updating to see if that fixes your issue. |
|
|
|
|
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
