PIC32 hair puller

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 , jamie snipped-for-privacy@charter.net says... [snip]

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.

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

unlock peripherals

these are my

A0, A1 sw

OC1CON sw zero,

zero, T2CON sw

zero, U1MODE sw zero,

zero, RTCCON sw

CM3CON sw zero,

CNCONB sw zero, RPA0R

t7, CFGCON

TRISB li t7, 0xFFFF

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.

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

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.

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.

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

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.

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.

That got changed after it was pointed out earlier.

And I thank you for it.

Thanks to everyone who responded.

Happy New Year to all.

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

That damn simulator! :)

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

Happy New Year..

Jamie