 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Geps
Joined: 05 Jul 2010
Posts: 129
|
| Input() On dsPIC33EP256GP502 |
 Posted: Mon Mar 16, 2015 5:23 pm |
 |
|
Hi,
I'm trying to read an Avago encoder via SPI on a dsPIC33EP256GP502.
I find when I disconnect the data line from the pic, I can see the encoder responding, but as soon as I reattach the PIC, the line stays at 0V.
My presumption is that something inside the PIC isn't being initialised correctly as I've verified the tris by explicitly setting it to 0xFFFF and checking the asm. Also, this pin seems to be a very heavily used one:
"TCK/CVREF1O/ASCL1/SDO1/RP40/T4CK/RB8".
For the moment, I'm bit banging the spi as I suspected there may be a spi register problem.
Could someone please have a look at my code and see if they concur as I can't see exactly why it isn't working.
Cheers,
| Code: | CCS PCD C Compiler, Version 5.025, 16548
ROM used: 726 bytes (0%)
Largest free fragment is 65536
RAM used: 139 (0%) at main() level
139 (0%) worst case
Stack used: 2 locations
Stack size: 128
*
00000: GOTO 218
....................
....................
....................
.................... #include <33EP256GP502.h>
.................... //////// Standard Header file for the DSPIC33EP256GP502 device ////////////////
.................... #device DSPIC33EP256GP502
....................
.................... #list
....................
....................
.................... #fuses NOWDT,NOPROTECT, HS
....................
.................... #use delay(clock=70M, xtal=20M) // Actual crystal is 20M
*
00200: CP0 W0
00202: BTSC.B 42.1
00204: BRA 216
00206: REPEAT #8B3
00208: NOP
0020A: REPEAT #3FFE
0020C: NOP
0020E: REPEAT #3FFE
00210: NOP
00212: DEC W0,W0
00214: BRA NZ,206
00216: RETURN
....................
.................... #define SPI_SS PIN_B7
....................
....................
....................
....................
.................... void main() {
00218: MOV #8F80,W15
0021A: MOV #8FFF,W0
0021C: MOV W0,20
0021E: NOP
00220: BSET.B 8C1.7
00222: MOV #46,W0
00224: MOV.B W0L,742
00226: MOV #57,W0
00228: MOV.B W0L,742
0022A: BCLR.B 742.6
0022C: MOV #25,W0
0022E: MOV W0,6C4
00230: MOV #1,W0
00232: MOV W0,680
00234: MOV #46,W0
00236: MOV.B W0L,742
00238: MOV #57,W0
0023A: MOV.B W0L,742
0023C: BSET.B 742.6
0023E: MOV #1,W4
00240: MOV W4,744
00242: MOV #13,W4
00244: MOV W4,746
00246: DISI #E
00248: MOV #103,W0
0024A: MOV #743,W1
0024C: MOV #78,W2
0024E: MOV #9A,W3
00250: MOV.B W2L,[W1]
00252: MOV.B W3L,[W1]
00254: MOV.B W0L,743
00256: LSR W0,#8,W0
00258: MOV #742,W1
0025A: MOV #46,W2
0025C: MOV #57,W3
0025E: MOV.B W2L,[W1]
00260: MOV.B W3L,[W1]
00262: MOV.B W0L,[W1]
00264: CLR 1000
00266: MOV #8000,W4
00268: MOV W4,220
0026A: MOV #400,W4
0026C: MOV W4,222
0026E: BCLR.B 220.3
00270: MOV #12,W4
00272: MOV W4,228
00274: CLR.B 1002
00276: CLR.B 1003
00278: CLR.B 1004
0027A: CLR.B 1005
0027C: CLR.B 1006
0027E: CLR 1008
00280: CLR.B 1007
00282: CLR E0E
00284: CLR E1E
00286: CLR.B 100A
.................... int8 i = 0x00;
.................... setup_adc_ports( NO_ANALOGS );
00288: CLR E0E
0028A: CLR E1E
.................... setup_adc(ADC_OFF);
0028C: CLR 320
.................... setup_comparator(1, NC_NC);
0028E: CLR A84
.................... setup_comparator(2, NC_NC);
00290: CLR A8C
.................... setup_comparator(3, NC_NC);
00292: CLR A94
.................... setup_comparator(4, NC_NC);
00294: CLR A9C
.................... setup_vref(VREF_DISABLED);
00296: CLR A82
.................... delay_ms(100);
00298: MOV #64,W0
0029A: CALL 200
.................... //output_float(PIN_B8);
.................... set_tris_b(0xFFFF);
0029E: SETM E10
.................... output_high(PIN_B9);
002A0: BCLR.B E11.1
002A2: BSET.B E15.1
.................... output_low(SPI_SS);
002A4: BCLR.B E10.7
002A6: BCLR.B E14.7
.................... delay_ms(100);
002A8: MOV #64,W0
002AA: CALL 200
.................... while (TRUE) {
.................... for (i=0x00; i<33; i++) {
002AE: CLR.B 100A
002B0: MOV.B 100A,W0L
002B2: SE W0,W0
002B4: MOV #21,W4
002B6: CP W4,W0
002B8: BRA LE,2C8
.................... output_toggle(PIN_B9);
002BA: BCLR.B E11.1
002BC: BTG.B E15.1
.................... delay_us(5);
002BE: REPEAT #AD
002C0: NOP
002C2: INC.B 100A
002C4: GOTO 2B0
.................... }
.................... output_high(PIN_B9);
002C8: BCLR.B E11.1
002CA: BSET.B E15.1
.................... delay_us(40);
002CC: REPEAT #576
002CE: NOP
002D0: GOTO 2AE
.................... }
.................... }
002D4: PWRSAV #0
Configuration Fuses:
Word 3L: 008B ICSP1 NOJTAG NODEBUG
H: FF00
Word 4L: 00F8 NOALTI2C1 NOALTI2C2 WDTWIN_25%
H: FF00
Word 5L: 007F WPOSTS16 WPRES128 PLLWAIT WINDIS NOWDT
H: FF00
Word 6L: 0066 HS NOOSCIO IOL1WAY CKSNOFSM
H: FF00
Word 7L: 0080 FRC IESO
H: FF00
Word 8L: 0003 NOWRT NOPROTECT
H: FF00
Word 9L: 0000
H: FF00
Word 10L: 0000
H: FF00 |
|
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Mon Mar 16, 2015 5:33 pm |
|
|
I don't use that PIC but as a general rule, you should disable any/all peripherals associated with the I/O pin you're using. IE if is has an ADC input, disable that, if it has comparator use, disable it, etc.
Also it's a good idea to just 'toggle' the I/O pin, say at 1 HZ to confirm it's the correct pin, especially if the PIC you're using has 'programmable pins' !
This will also confirm the correct selection of clock speed, dividers, etc.
Jay |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Mar 16, 2015 6:20 pm |
|
|
Post the p/n of your Avago encoder.
Post a list of all connections between the PIC board and the encoder.
Describe your test. Are you testing "hot plugging" of the cable between
the encoder and the PIC board ? Are you yanking the cable in the
middle of an on-going SPI transaction, and the re-plugging it and hoping
the transaction will continue where it left off ?
Are you only disconnecting the SDI line coming into the PIC, or are you
disconnecting other lines at the same time (SCK, CS, power, etc.) ?
Do you have any pull-up or pull-down resistors on the PIC board, on
any of the lines that you are yanking ? |
|
|
Geps
Joined: 05 Jul 2010
Posts: 129
|
|
| Posted: Tue Mar 17, 2015 12:28 am |
|
|
| Quote: | I don't use that PIC but as a general rule, you should disable any/all peripherals associated with the I/O pin you're using. IE if is has an ADC input, disable that, if it has comparator use, disable it, etc.
Also it's a good idea to just 'toggle' the I/O pin, say at 1 HZ to confirm it's the correct pin, especially if the PIC you're using has 'programmable pins' !
This will also confirm the correct selection of clock speed, dividers, etc.
Jay |
Thanks Jay,
Yes sorry, I have already done that. At least I've explicitly disabled everything I can see that I can disable, whether on that pin or not.
Clock speed etc is all good and I can printf with no problems.
| Quote: |
Post the p/n of your Avago encoder.
|
AEAT-6600-T16
http://www.avagotech.com/pages/en/motion_control_encoder_products/magnetic_encoders/aeat-6600-t16/
| Quote: |
Post a list of all connections between the PIC board and the encoder.
|
See below
| Quote: |
Describe your test. Are you testing "hot plugging" of the cable between
the encoder and the PIC board ? Are you yanking the cable in the
middle of an on-going SPI transaction, and the re-plugging it and hoping
the transaction will continue where it left off ?
|
Due to the required precision of the magnet above the encoder, I've got my own pcb with PIC on one side and encoder on the reverse.
I power the device up, and it holds the SS line low (I'm using the 2 wire SSI mode - essentially you just keep CS low) and then the PIC generates the clock signal. My logic analyser shows the clock and SS lines at the values I expect but the (bidirectional) data line as flat with very brief intermittent noise (1us pulse every 10-20seconds).
I cut the data line track leaving the encoder's pin floating, redo my test and can now see the encoder replying to the clock signal. This is consistent when repeated (3 times so far) - as soon as the PIC is disconnected, the line goes high/low as I'd expect to see.
| Quote: |
Are you only disconnecting the SDI line coming into the PIC, or are you
disconnecting other lines at the same time (SCK, CS, power, etc.) ?
|
As above, 1 track cut, nothing more.
| Quote: |
Do you have any pull-up or pull-down resistors on the PIC board, on
any of the lines that you are yanking ?
|
This is an explanation of the encoder's pins voltages and what's attached to them:
| Code: |
Pin Name Voltage Notes
1 - A/U 3.261 Not Connected
2 - B/V 3.267 NC
3 - I/W 3.270 NC
4 - MAG HI 0.016 47K Pull down
5 - MAG LO ~0.016 from memory when tested with magnet 47K Pull down
6 - GND 0.013
7 - ALIGN 0.020 47K Pull down
8 - PWM 0.020 NC
9 - VDD 3.288 10uf decoupled
10 - VDD_F 3.290 100nf decoupled (tied to VDD rail)
11 - PWRDOWN 0.030 47K Pull down
12 - VPP 3.291 100nf decoupled
13 - PROG 0.016 47K Pull down
14 - NCS 0.244 Connected to PIC
15 - CLK 1.914 Connected to PIC, 47K pull down
16 - DO/DI 0.242 Connected to PIC.
|
PIC has 10K pullup on MCLR, 10uF VCap and 20MHz crystal oscillator - all other pins are unpopulated since I stripped everything back.
Cheers, |
|
|
Geps
Joined: 05 Jul 2010
Posts: 129
|
|
| Posted: Tue Mar 17, 2015 12:31 am |
|
|
Current test program:
| Code: |
#fuses NOWDT,NOPROTECT, HS, ICSP3
#use delay(clock=70M, xtal=20M)
#define SPI_SS PIN_B7
#PIN_SELECT U1TX=PIN_A4
#PIN_SELECT U1RX=PIN_B5
#use rs232(STREAM=RX_SERIAL, XMIT=PIN_B4, RCV=PIN_B3, baud=115200, ERRORS, UART1)
void main() {
int8 i = 0x00;
setup_adc_ports( NO_ANALOGS );
setup_adc(ADC_OFF);
setup_comparator(1, NC_NC);
setup_comparator(2, NC_NC);
setup_comparator(3, NC_NC);
setup_comparator(4, NC_NC);
setup_vref(VREF_DISABLED);
delay_ms(100);
//output_float(PIN_B8);
set_tris_b(0xFFFF);
output_high(PIN_B9);
output_low(SPI_SS);
delay_ms(100);
while (TRUE) {
for (i=0x00; i<33; i++) {
//fprintf(RX_SERIAL, "Started\n");
output_toggle(PIN_B9);
delay_us(5);
}
output_high(PIN_B9);
delay_us(40);
}
} |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19506
|
|
| Posted: Tue Mar 17, 2015 2:23 am |
|
|
Don't fiddle about, use the SPI library:
| Code: |
#define SPI_SEL PIN_B7
#define SPI_CLK PIN_B9
#define SPI_DATA //You don't tell us what pin this is....
#use spi(MODE=3, BAUD=1MHz, CLK=SPI_CLK, DI=SPI_DATA, ENABLE=SPI_SEL, BITS=16, ENABLE_DELAY=1, STREAM=AV02)
#use rs232(STREAM=RX_SERIAL, XMIT=PIN_B4, RCV=PIN_B3, baud=115200, ERRORS, UART1)
void main() {
unsigned int16 data;
setup_adc_ports( NO_ANALOGS );
setup_adc(ADC_OFF);
setup_comparator(1, NC_NC);
setup_comparator(2, NC_NC);
setup_comparator(3, NC_NC);
setup_comparator(4, NC_NC);
setup_vref(VREF_DISABLED);
output_high(SPI_SEL);
output_high(SPI_CLK); //ensure pins are inactive
delay_ms(100); //10mSec minimum required
while (TRUE)
{
data = SPI_XFER(AV02, 0,16); //transfer 16 bits
fprintf(UART1,"Data %04LX\n\r",data);
delay_ms(100);
}
}
|
You seem to be trying to clock 16.5 bits (toggling 0 to 32) - the chip returns 16bits, with the select line permanently low. You can do this (2 wire interface mode), but you are dangerously close (under....) the minimum clock rate specified for the chip (10uSec per cycle). |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Tue Mar 17, 2015 5:27 am |
|
|
| Quote: | | #define SPI_DATA //You don't tell us what pin this is.... |
Appears to be B8.
I'm no expert on the dspic33s, but as far as I understand it, that's one of the alternative SPI data output from the PIC (SDO). As the sensor is always outputting, to have any chance of using the hardware SPI you need to wire it to an SPI data input, SDI.
What you are seeing is a hardware clash - something in the PIC is driving B8 low, clashing with the sensor also driving it. Therefore one of B8s functions is not turned off. I don't know which function. You need to check all its possible functions and turn off, or relocate, the corresponding peripherals.
SPI does not usually work with bidirectional signals (note the sensor data sheet calls it SSI...), but there is no SPI standard, and bi-directional is sometimes used, probably to save a pin. In this case, input is probably only used during configuration. Once configured the sensor only ever outputs on the pin. The CCS C SPI code doesn't seem to have a bi-direction mode, and so doesn't support it. But it doesn't need to, it just needs to receive data from the sensor. There's no real reason why the PIC's hardware SPI cannot be used, and none for not using CCS C's support for both hard and soft SPI. Just find out what other function is driving the pin, or better yet, use an SDI (input) rather than SDO (output) pin and use the compiler's SPI functions. |
|
|
Geps
Joined: 05 Jul 2010
Posts: 129
|
|
| Posted: Tue Mar 17, 2015 6:57 am |
|
|
| Ttelmah wrote: | Don't fiddle about, use the SPI library:
You seem to be trying to clock 16.5 bits (toggling 0 to 32) - the chip returns 16bits, with the select line permanently low. You can do this (2 wire interface mode), but you are dangerously close (under....) the minimum clock rate specified for the chip (10uSec per cycle). |
Thanks Ttelmah,
I'm pretty sure though the maximum clock period is 20us per cycle, at least that's what I got from the datasheet so I should be well within it. The 0.5 clock bit is because the clock needs to stay high inbetween reads so the encoder can load new data.
Will try the code you posted later when I have the hardware to hand and report back.
| RF_Developer wrote: | | Quote: | | #define SPI_DATA //You don't tell us what pin this is.... |
Appears to be B8.
I'm no expert on the dspic33s, but as far as I understand it, that's one of the alternative SPI data output from the PIC (SDO). As the sensor is always outputting, to have any chance of using the hardware SPI you need to wire it to an SPI data input, SDI.
What you are seeing is a hardware clash - something in the PIC is driving B8 low, clashing with the sensor also driving it. Therefore one of B8s functions is not turned off. I don't know which function. You need to check all its possible functions and turn off, or relocate, the corresponding peripherals.
SPI does not usually work with bidirectional signals (note the sensor data sheet calls it SSI...), but there is no SPI standard, and bi-directional is sometimes used, probably to save a pin. In this case, input is probably only used during configuration. Once configured the sensor only ever outputs on the pin. The CCS C SPI code doesn't seem to have a bi-direction mode, and so doesn't support it. But it doesn't need to, it just needs to receive data from the sensor. There's no real reason why the PIC's hardware SPI cannot be used, and none for not using CCS C's support for both hard and soft SPI. Just find out what other function is driving the pin, or better yet, use an SDI (input) rather than SDO (output) pin and use the compiler's SPI functions. |
Yes, I agree it's a hardware clash, but I can't be sure which hardware exactly as from my understanding they are all off either implied or explicitly:
The pin also has on it:
TCK - JTAG has been disabled in the fuse section
CVREF1O - All comparator's have been explicitly set to off
ASCL1 - I2C is unused (is there an explicit switch off command?)
SDO1 - SPI1 is unused (is there an explicit switch off command?)
RP40 - no PPS functions have been set
T4CK - Timer 4 is unused (again, is there an explicit switch off command?)
RB8
The plan was to use the SPI hardware but SPI2 which is remappable with the PPS function...it's just unfortunate that it's over the top of the pins for SPI 1 but as I said, there wasn't room to run the tracks as I wanted to use SPI1 as it works.
Cheers, |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Tue Mar 17, 2015 8:22 am |
|
|
Might need to dump the listing and compared the actual fuses and registers set to disable 'things' as it might be the compiler version sets the wrong bits.
You'll have to 'play computer' and compare what was coded versus what's in the datasheets.
Jay |
|
|
Geps
Joined: 05 Jul 2010
Posts: 129
|
|
| Posted: Tue Mar 17, 2015 12:17 pm |
|
|
I've had a look through and I can't see any registers getting set that would cause what I'm seeing...on the assumption that they are starting up with the 0x0000 value it states in the datasheet.
I've tried Ttelmah's code and it generates the same results as I had before - activity on the data line when disconnected, changing to a flat 0V when the pic is connected.
I'm going to try a new set of hardware just to rule out anything from that perspective and see if that shines any light on the problem. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19506
|
|
| Posted: Tue Mar 17, 2015 12:35 pm |
|
|
The timeout behaviour occurs at 20uSec, but the minimum clock speed is specified at 100KHz.
The SPI is not bi-directional. It's like half duplex serial. For receive only, you can ignore the transmission side.
None of the other things on these pins should affect anything. JTag is disabled, which is the only connection that would cause problems.
I'd step back. Leave the chip disconnected and verify that you can toggle each pin used for this interface. Then test you can read an input on each pin. There shouldn't be data output by the chip, unless the clock is actually operating. |
|
|
Geps
Joined: 05 Jul 2010
Posts: 129
|
|
| Posted: Tue Mar 17, 2015 4:10 pm |
|
|
Thanks Ttelmah,
Turns out it was the PIC that was faulty. Recreated the circuit with new components on another PCB and it worked first time.
Thanks for the suggestions,
Cheers, |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19506
|
|
| Posted: Wed Mar 18, 2015 1:07 am |
|
|
Well done.
This is why 'stepping back' is one of the most powerful tools.
Just had it yesterday, with new code for a customer, that wouldn't work. Fortunately, they use the same basic board for another project for which I had working code, so I asked them to put this code into the board. Lo and behold, this 'known working' code, gave exactly the same fault....
Pointed this out, and suggested they got the hardware working first. 
Often I'll spend the time to make an 'infantile' test program, that just operates lines, and reads lines, to verify the hardware is working, before even starting on the main code. |
|
|
|
|
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
