PIC32 hair puller

R

Randy Day

Guest
This _should_ be PIC Assembly 101; I know
I'm missing something obvious, but I'm still
missing it.

Using a PIC32MX150, I'm trying to access the
i/o pins on PORTA and PORTB. For some reason,
A0, A1, B0-B3 and B12-B15 don't want to
participate.

The last 4 lines are a loop to invert the
ports over and over; the simulator shows
the other port pins flipping.

Everything else is just me trying to shut
off whatever is hogging those i/o pins.

HELP! My hairline is receding faster than
nature intended! :)

li t7, 0
sw t7, CFGCON #clear CFGCON lock bit to unlock peripherals

sw zero, SPI1CON
sw zero, IC1CON
sw zero, IC2CON # these are my attempts to shut off
sw zero, IC3CON # whatever is locking up A0, A1
sw zero, IC4CON # B0-3 and B12-15
sw zero, IC5CON
sw zero, OC1CON
sw zero, OC2CON
sw zero, OC3CON
sw zero, OC5CON
sw zero, T1CON
sw zero, T2CON
sw zero, T3CON
sw zero, I2C1CON
sw zero, I2C2CON
sw zero, U1MODE
sw zero, U2MODE
sw zero, PMCON
sw zero, PMAEN
sw zero, DMACON
sw zero, RTCCON
sw zero, AD1CON1
sw zero, CM1CON
sw zero, CM2CON
sw zero, CM3CON
sw zero, CVRCON
sw zero, CTMUCON
sw zero, CNCONA
sw zero, CNCONB
sw zero, RPA0R
sw zero, RPA1R

li t7, 6144 # bit 13, 12 set, lock peripherals
sw t7, CFGCON

sw zero, TRISA # set all ports to output
sw zero, TRISB
li t7, 0xFFFF #load this value into the INV regs
test:
sw t7, PORTAINV
sw t7, PORTBINV
b test
nop

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
 
In article <MPG.2d2668c2cadb5f38989681@202.177.16.121>,
randy.day@sasktel.netx says...
This _should_ be PIC Assembly 101; I know
I'm missing something obvious, but I'm still
missing it.

Using a PIC32MX150, I'm trying to access the
i/o pins on PORTA and PORTB. For some reason,
A0, A1, B0-B3 and B12-B15 don't want to
participate.

The last 4 lines are a loop to invert the
ports over and over; the simulator shows
the other port pins flipping.

Everything else is just me trying to shut
off whatever is hogging those i/o pins.
Click to expand...

I didn't include your source code but, do you have some other code
in the background operating? Like ISR'?

Any code that operates in the background under interrupt control, etc,
can play with your head.

If you are using this on a DEV board that has a boot loader in it or
some other support code operating, it's very possible this is your
problem.

Jamie
 
In article <MPG.2d268d255f54502f989729@news.eternal-september.org>,
jamie_ka1lpa@charter.net says...

[snip]

I didn't include your source code but, do you have some other code
in the background operating? Like ISR'?

Any code that operates in the background under interrupt control, etc,
can play with your head.
Click to expand...

There shouldn't be any. I have a .text
section, .set noreorder, .ent main, and
then this code, which I step through with
the simulator. I'm very much at the
'hello world' stage with these mips
thingies.

I've tried writes to LATx and PORTx,
same results. Could there be an
interrupt-related register that grabs
i/o pins?

When I encountered problems like this
with older pics, it was usually because
some peripheral had control of them. Thus
my attempt to turn everything off.
 
In article <MPG.2d26c51064f66e6c989680@aioe.org>, randy.day@sasktel.netx
says...
In article <MPG.2d268d255f54502f989729@news.eternal-september.org>,
jamie_ka1lpa@charter.net says...

[snip]

I didn't include your source code but, do you have some other code
in the background operating? Like ISR'?

Any code that operates in the background under interrupt control, etc,
can play with your head.

There shouldn't be any. I have a .text
section, .set noreorder, .ent main, and
then this code, which I step through with
the simulator. I'm very much at the
'hello world' stage with these mips
thingies.

I've tried writes to LATx and PORTx,
same results. Could there be an
interrupt-related register that grabs
i/o pins?

When I encountered problems like this
with older pics, it was usually because
some peripheral had control of them. Thus
my attempt to turn everything off.
Click to expand...

It sounds to me you have other code operating..

I wouldn't think you should have a problem in a stimulator
unless it has previsions to allocate some IO as background
operations.
If the emulator is designed to work with a micro controller
board, like a beagle bone for example, it's possible it knows which
pins are being used for the background. In those boards, you are
basically running an OS already..

Jamie
 
On Thu, 26 Dec 2013 16:25:10 -0600, Randy Day wrote:

This _should_ be PIC Assembly 101; I know I'm missing something obvious,
but I'm still missing it.

Using a PIC32MX150, I'm trying to access the i/o pins on PORTA and
PORTB. For some reason,
A0, A1, B0-B3 and B12-B15 don't want to participate.

The last 4 lines are a loop to invert the ports over and over; the
simulator shows the other port pins flipping.

Everything else is just me trying to shut off whatever is hogging those
i/o pins.

HELP! My hairline is receding faster than nature intended! :)

li t7, 0 sw t7, CFGCON #clear CFGCON lock bit to
unlock peripherals

sw zero, SPI1CON sw zero, IC1CON sw zero, IC2CON #
these are my
attempts to shut off sw zero, IC3CON # whatever is locking up
A0, A1 sw
zero, IC4CON # B0-3 and B12-15 sw zero, IC5CON sw zero,
OC1CON sw zero,
OC2CON sw zero, OC3CON sw zero, OC5CON sw zero, T1CON sw
zero, T2CON sw
zero, T3CON sw zero, I2C1CON sw zero, I2C2CON sw
zero, U1MODE sw zero,
U2MODE sw zero, PMCON sw zero, PMAEN sw zero, DMACON sw
zero, RTCCON sw
zero, AD1CON1 sw zero, CM1CON sw zero, CM2CON sw zero,
CM3CON sw zero,
CVRCON sw zero, CTMUCON sw zero, CNCONA sw zero,
CNCONB sw zero, RPA0R
sw zero, RPA1R

li t7, 6144 # bit 13, 12 set, lock peripherals sw
t7, CFGCON

sw zero, TRISA # set all ports to output sw zero,
TRISB li t7, 0xFFFF
#load this value into the INV regs
test:
sw t7, PORTAINV sw t7, PORTBINV b test nop

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Click to expand...

I dunno the new PIC stuff, but it's always a good idea to check the setup
registers after you set them -- sometimes the hardware doesn't let you
write to bits that you think you have.

At times like these I'll open the manual and compare the peripheral setup
registers against the debugger's report bit-by-bit. Sometimes the value
that comes out is reading about some setup sequence that I missed before.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
 
In article <MPG.2d27b780b4e40ee798972a@news.eternal-september.org>,
jamie_ka1lpa@charter.net says...

[snip]

It sounds to me you have other code operating..
I wouldn't think you should have a problem in a stimulator
Click to expand...

Well I can certainly say that I don't have
enough stimulators in my life! :) :)

unless it has previsions to allocate some IO as background
operations.
Click to expand...

This is in MPLAB; unless MIPS needs that
kind of thing, I've never encountered
any background processes in any other
MC device. Maybe in C pre-processor
code, but never in asm.

If the emulator is designed to work with a micro controller
board, like a beagle bone for example, it's possible it knows which
pins are being used for the background. In those boards, you are
basically running an OS already..
Click to expand...

That's the hair-pulling thing about this:
this hasn't even been sent to silicon yet.
This is behavior in the simulator, and
there's no way they'd have borked
something so basic.

One thing I did note after reading a bit
more: the pins involved ARE linked to the
analog i/o stuff. But I've cleared the
ANSELx registers, so I must be missing
something else. It's some bit in some
overlooked register...

Sigh. <shuffles off to the PDF reader...>
 
In article <MPG.2d2815284c8e9f23989681@aioe.org>, randy.day@sasktel.netx
says...
hat's the hair-pulling thing about this:
this hasn't even been sent to silicon yet.
This is behavior in the simulator, and
there's no way they'd have borked
something so basic.

One thing I did note after reading a bit
more: the pins involved ARE linked to the
analog i/o stuff. But I've cleared the
ANSELx registers, so I must be missing
something else. It's some bit in some
overlooked register...

Sigh. <shuffles off to the PDF reader...
Click to expand...

Ok, just a winger, since this is an analog function
you cleared, is it possible you didn't set the pin for
output mode and it's sitting in input mode?

I have forgotten the code you posted before, so maybe you
already did this.. If so, you may need to first clear the
AnSelx bits and then set the direction for the io.. Just
a thought. Also, if you have options to enable full totem outputs
instead of sink only, like a few do.

Jamie
 
In article <MPG.2d2668c2cadb5f38989681@202.177.16.121>,
randy.day@sasktel.netx says...
This _should_ be PIC Assembly 101; I know
I'm missing something obvious, but I'm still
missing it.

Using a PIC32MX150, I'm trying to access the
i/o pins on PORTA and PORTB. For some reason,
A0, A1, B0-B3 and B12-B15 don't want to
participate.

The last 4 lines are a loop to invert the
ports over and over; the simulator shows
the other port pins flipping.

Everything else is just me trying to shut
off whatever is hogging those i/o pins.

HELP! My hairline is receding faster than
nature intended! :)

li t7, 0
sw t7, CFGCON #clear CFGCON lock bit to unlock peripherals

sw zero, SPI1CON
sw zero, IC1CON
sw zero, IC2CON # these are my attempts to shut off
sw zero, IC3CON # whatever is locking up A0, A1
sw zero, IC4CON # B0-3 and B12-15
sw zero, IC5CON
sw zero, OC1CON
sw zero, OC2CON
sw zero, OC3CON
sw zero, OC5CON
sw zero, T1CON
sw zero, T2CON
sw zero, T3CON
sw zero, I2C1CON
sw zero, I2C2CON
sw zero, U1MODE
sw zero, U2MODE
sw zero, PMCON
sw zero, PMAEN
sw zero, DMACON
sw zero, RTCCON
sw zero, AD1CON1
sw zero, CM1CON
sw zero, CM2CON
sw zero, CM3CON
sw zero, CVRCON
sw zero, CTMUCON
sw zero, CNCONA
sw zero, CNCONB
sw zero, RPA0R
sw zero, RPA1R

li t7, 6144 # bit 13, 12 set, lock peripherals
sw t7, CFGCON

sw zero, TRISA # set all ports to output
sw zero, TRISB
li t7, 0xFFFF #load this value into the INV regs
test:
sw t7, PORTAINV
sw t7, PORTBINV
b test
nop

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Click to expand...
Just some guesses, but on most PICs any pin that is multiplexed with an
analog in is set to analog in on reset. You must turn off the analog
system for any digital IO.
Also, when writing OUT on a port you should be using the LATA port A
latch, NOT by writing to the port address. You read the port by loading
the PORTA register, you write the port by writing to LATA the PORTA
output latch.

That's all I've got.
 
In article <MPG.2d2bbd7460f8391e98be38@news.east.earthlink.net>,
Asgard24@mindspring.com says...

[snip]

Just some guesses, but on most PICs any pin that is multiplexed with
an analog in is set to analog in on reset. You must turn off the
analog system for any digital IO.
Click to expand...

I did in fact turn off tha ADC and set ANSEL
bits to 0. For whatever reason, the simulator
still won't activate the I/O. My next attempt
will be to program a micro, and see if it
actually works on hardware.

Also, when writing OUT on a port you should be using the LATA port A
latch, NOT by writing to the port address. You read the port by
loading the PORTA register, you write the port by writing to LATA the
PORTA output latch.
Click to expand...

That got changed after it was pointed out
earlier.

> That's all I've got.

And I thank you for it.
 
In article <MPG.2d2c04bdb918415b989682@aioe.org>, randy.day@sasktel.netx
says...
In article <MPG.2d2bbd7460f8391e98be38@news.east.earthlink.net>,
Asgard24@mindspring.com says...
Click to expand...

I finally had a chance to put the program
on a chip. It turns out all outputs are
actually outputs, despite what the simulator
says.

Thanks to everyone who responded.

Happy New Year to all.

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
 
In article <MPG.2d2e481929df9b27989682@202.177.16.121>,
randy.day@sasktel.netx says...
In article <MPG.2d2c04bdb918415b989682@aioe.org>, randy.day@sasktel.netx
says...
In article <MPG.2d2bbd7460f8391e98be38@news.east.earthlink.net>,
Asgard24@mindspring.com says...

I finally had a chance to put the program
on a chip. It turns out all outputs are
actually outputs, despite what the simulator
says.

Thanks to everyone who responded.

Happy New Year to all.
Click to expand...

That damn simulator! :)

Don't fret, I find gross failures in circuit simulators, too.

Happy New Year..

Jamie
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top