This simple PIC24 assembly code doesn't execute. I don't know why.

[Rich D.]

After much grief getting assembly code to compile and download on MPLAB-X, I have everything I ever dreamed of, but this dream turned into something less than I expected. For reasons unknown to me, this simple LED flash code doesn't seem to execute. It does simulate OK in MPLAB V8.xx

The two pins I want to use as LED outputs are named "TDI/PMA9/CN35/RA9", and "TMS/PMA2/PMALU/CN36/RA10".

On the PIC24FJ128GA406, these port A pins are not on the peripheral pin select list, so that's not it. They share a function with JTAG, but if I'm not mistaken that function is normally disabled. They also share Parallel Master Port output port functions, and I believe that is disabled on reset also. They also share with interrupt-on-change inputs. They are also not analog input pins which would be the default state. So what else is left? This is the simple looping code, with a short delay between state changes:

;BCLR ANSELx, #9 no analog function on '204 chip
;BCLR ANSELx, #10 "
BCLR TRISA, #9 ;OUTPUT PORT A BIT 9
BCLR TRISA, #10 ;OUTPUT PORT A BIT 10
BCLR ODCA, #9 ;DISABLE OPEN-DRAIN OUTPUT MODES if used (yes on '204)
BCLR ODCA, #10

;..............................................................................
; MAIN LOOP BEGINS HERE
;..............................................................................
infiniteloop:
;turn on 9 (10 off)
BCLR LATA, #10
BSET LATA, #9
CALL DELAY_A_BUNCH
;turn on 10 (9 off)
BCLR LATA, #9
BSET LATA, #10
CALL DELAY_A_BUNCH
done:
BRA infiniteloop
;..............................................................................
; MAIN LOOP END
;..............................................................................


;..............................................................................
;Subroutine: Delay a bunch (not calibrated to any specific time)
;..............................................................................
DELAY_A_BUNCH:
push.d w0
clr.w w0
clr.w w1
Outer_Loop: nop
Inner_Loop: nop
inc.b w0,w0
bra nz, Inner_Loop
inc.b w1,w1
bra nz, Outer_Loop
pop.d w0
return

Any answers to this puzzle or even educated guesses would be most welcome. I might* even accept an insult or two if it will shed light on the puzzle.

* might, not will...might

 

[Rich D.]

Hint: I'm thinking that the '204 chip I am using has volatile configuration bits. If that is the case these bits need to be programmed right after power-up. So now I got to figure that out.

 

[Ian Rogers]

Be aware... "DELAY_A_BUNCH:" takes forever in simulation.... when I tested this I commented out the the inner loop!!

It seems as if the code stops, but it really hasn't!!

 

[Rich D.]

According to the simulation stopwatch, it is only a cycle of milliseconds in the DELAY_A_BUNCH. Meanwhile, in hardware I let the thing sit for hours and only the LED2 remains lit. BTW, without code or when in reset LED2 is lit, so it appears the software isn't doing anything at all, especially since the software is supposed to start with LED1 lit and LED2 off. I've had PIC assembly bugs before, but never where I couldn't even successfully flash a frickin' LED!

I guess that is another symptom: While the two LEDs are connected to IO pins and nothing else, the pins themselves are expected to be reset as inputs on power-up as usual on all PICs. So why is LED2 on by default?
This is a Microchip 24F Curosity board. Either something else is going on or they sent me a defective board. I think something else is going on. I might not have the config bits set correctly.

 

[Ian Rogers]

Okay... If the delay is in the order of mill seconds, then lighting and extiguising the LED will not be seen by the human eye..

BTW the JTAG is enabled at powerup... One of your Config bits!!!

 

[Rich D.]

JTAG, huh? That's what I was afraid of.

I'm spending all day reading through all the documentation on the config bits, and had to re-direct to the oscillator modes to make sure I have those clock config bits right.
They made this part more complicated with these newer chips compared with the older dsPIC30F's.
It might have been another few weeks before I got around to read the JTAG stuff! I will re-direct my efforts to kill that JTAG junk.

The delay is fine - I forget what I calculated but at 8 MHz clock it was 60-something mSec maybe?? I would have seen it with an oscilloscope.
Also, if the delay was the only problem, I'd see both LEDs at 1/2 briteness, but #1 never, ever, ever goes on, and #2 never, ever, ever goes off.

JTAG junk probably.

 

[Ian Rogers]

Looking at the PIC24FJ128GA406!! Its a 64 pin device... There is no LATA 9 or 10... Only the 100 pin and 120 pin devices have RA9 and 10.. (PIC24FJ128GA410 and PIC24FJ128GA412) What pins are you using?

 

[Rich D.]

Sorry, I'm working with three different processor types and I got confused. The '406 is the eventual processor I will be using in one project, BUT:

The Microchip 24F Curiosity Development Board has a '204 on it as was stated in my code comment. Specifically it is a PIC24FJ128GA204, with the Port A pins 9 & 10 connected to LEDs to ground.

I wish they would name these chips "Mustang", "George", "Jennifer", "Spike", "Harley", "Cheddar", or something memorable instead of 1243F90TR78K534F89E79S78912G4632BWH84123K3198R48S321645C1331-2

 

[Ian Rogers]

Yes!! Then dissable the JTAG as both those pins are set to inputs!! Bit 14 of config word 1

 

[Rich D.]

Yes, I have been working on config bits since you informed me JTAG was defaulted to on. So I'm trying to learn how to setup the config bits - another thing that's changed since the good ol' days of PIC30's.
As usual there is very little documentation for setting the configuration bits without that g@d$%^& C language.

 

[Ian Rogers]

You can do it directly from MPLABX... All the options are in the docs/config-docs folder...

#pragma config option = switch .. ..... etc.... I think its the same as C

 

[Rich D.]

Yes I saw that and it makes setting the config bits easy. Only problem with that is that I am now using assembly like I wanted to, and the "#pragma" stuff it creates generates assembly errors. It's more C-code!

 

[Ian Rogers]

I found the answer in the pic24xxx.inc file

config __CONFIG1, JTAGEN_OFF

config is a macro... I'm not sure about the names but the values are all listed

 

[jpanhalt]

Hi Rich,

I searched on setting configuration PIC 24F in Assembly and this popped up: https://www.microchip.com/forums/m684715.aspx

See post #2 "SOLVED". Apparently, it can be done in the usual way -- at least for that chip. I would find it odd if other 24F's required a different language to do the same thing.

John

Edit: Just saw Ian's comment. Be sure you use the double underscore.

 

[jpanhalt]

config is a macro... I'm not sure about the names but the values are all listed

Isn't that what C is too?

John

Para C oprima ocho por favor

 

[Rich D.]

I found this config __CONFIG code in some other inc files towards the bottom. There are lines to define pretty much every possible config bit state.

I inserted that line "config __CONFIG1, JTAGEN_OFF" in an odd place right in the middle of the code after reset and 1st stack pointer write...

...saved...compiled...downloaded...

BOOM! There it is, flashing big and brite, left and right like a railroad warning light, rate about 3Hz. I now have assembly code control of a PIC24 chip!

The rest of course will be easy!

THANK YOU EVERYBODY!
I would be mocked and driven out of town without your help getting this stuff to work. You'all are much more helpful than Microchip is!

 

[jpanhalt]

THANK YOU EVERYBODY!
I would be mocked and driven out of town without your help getting this stuff to work. You'all are much more helpful than Microchip is!

It's like that old MasterCard advertisement: PIC 24FJ128GA204, $3.95 each. How to turn it on, priceless.

Good luck. I plan to use these threads this Winter when I venture into a 24F chip.

John

 

[Rich D.]

How to turn it on, priceless.

EXACTLY!

Well when I get enough of this stuff figured out, I will post the code for the 3 new chips I have to do.

Maybe someday when people ask how can I program ...xxx... in assembly, they won't be met with 100 responses that ask "Why don't you use C?".
My favorite part is when they all say "C these days can create code that is almost as compact and efficient as assembly!", what I hear is:
"C these days can create code that is almost as compact and efficient as assembly!" Almost means "less than".

And then they mention how you can "optimize" code by doing parts of it in assembly...virtually admitting that C can't do everything well. So I ask, why not "optimize" all of it?
They say it's more efficient when you are paying a team to develop software commercially. I am not doing that. You can, but I am not. Your preferred tools are not my preferred tools.
I've read where some smarter managers that have people coding in BASIC have been even quicker to develop projects than those in C, and spent even less coding and training time and money.
Someday C will be an old language we laugh at. Assembly will still be around.

I enjoy programming bits in assembly and I am not going to apologize for it. I don't give a damn if it takes me longer. That means more time to enjoy programming. That also means anybody paying me can pay me more hours for it.

 

[jpanhalt]

Someday C will be an old language we laugh at. Assembly will still be around.

But maybe not for Microchip stuff.

 

[Ian Rogers]

Someday C will be an old language we laugh at. Assembly will still be around.

Doubt it... Virtually all micro's designed today are C optimised... This makes it an easier job for C programmers.

The Unix oS its self was built with C for C.... C++ compiles to C and then C compiles to ASM, Both will be here for ever!!