Microchip hints, bug fixes, and work arounds.

[jpanhalt]

PicKit 3 problem with 12F683 and 16F1938

Here is a related post: https://www.electro-tech-online.com/threads/pickit-3-repairable.132599/#post1106530

Conditions:
1) PK3 powered with USB
2) Target attached to adapter board and powered by PK3. The adapter board simply brings the chip's pinouts to the PK3. Nothing else is on the adapter.
3) Power set to 5V
4) MPLab 8.89
5) Tested with and without a 0.1 uF decoupling capacitor across Vdd and Vss
6) Chip = 12F683

Problem Description:
When the PK3 is set to power target at 5V, it does not recognized the target and generates this error code: "PK3Err0035 Failed To Get Device ID"

Workarounds:
1) Lower voltage to 4.75V or lower. If the voltage is set too low, such as 3.5V, you will get another error code: Target Device ID (00000000) does not match expected Device ID (00000460).
2) Use an external 5V power source for the target.

Additional Information:
Workaround was reported by "mrp" on the Microchip forum. According to him, this issue also affects the 16F1938.

I observed Vdd using an oscilloscope. During successful programming with the PK3 powering the target (e.g., 3.5V < V ≤ 4.75V), Vdd drops to zero (Vss) for three short periods ("blips"). The first blip was about 20 mS wide; the second was about 12 mS wide; and the third was about 12 mS wide. The first two blips are about 20 to 40 mS apart. The third blip is separated from the first two by about 2 seconds. At 5V, there were only 2 blips about 1 second apart. With external power, there are no blips.

Comment:
I suspect this problem is related to an inability of the PK3 to maintain Vdd during initialization. The observed intervals don't make a lot of sense to me, except, the patterns were distinctly different. The intervals and blip widths were not particularly reproducible. Why this only affects some chips is a mystery.

John

 

[()blivion]

Super secret hidden menu in MPLAB 8 Logic analyzer.

Hi

Maybe this is well known, maybe it's not. But there is this fairly odd, fairly obscure menu hidden in the Logic analyzer for MPLAB 8. The menu can be opened by right clicking the gray bar to the right of all the buttons, then clicking the non descript "Edit" text. And so far, that is the only way I have found to access it.



It looks very advanced, and it's also seems to be full of bugs, almost like it was a planed feature that wasn't supposed to be accessible yet, or behind the scenes MPLAB devs eyes only stuff, or an ester egg or something, IDK. I never really play with it, but it looks like it could be very useful. It's packed full of stuff. And I have always though the logic analyzer was somewhat lacking otherwise. Here is what the menu looks like.



Does anyone know where to get documentation on this? I have STFW and RTFM but... crickets. /)

 

[3v0]

Maybe we can get this move to
Microchip hints, bug fixes, and work arounds.

[MODNOTE]Done as requested[/MODNOTE]

 

[jpanhalt]

Hi

Does anyone know where to get documentation on this? I have STFW and RTFM but... crickets. /)

Does this help?

https://www.electro-tech-online.com/custompdfs/2013/02/MPLAB_User_Guide_51519c.pdf

13.15 LOGIC ANALYZER WINDOW
This window acts like a real logic analyzer, displaying the digital levels of all the
selected pins during a selected time period.

Documentation follows that.

John

 

[()blivion]

Oh, so I should have posted in this in this thread? OK then, my bad.

Anyway, it's not the logic analyzer window that is the problem, I am very familiar with that, I use it all the time.

It that there is another window inside the logic analyzer, an "advanced menu". And there is apparently NO information on it that I have seen. Search the user guide, you will find that in all 58 instances of the words "Logic Analyzer" not a single one even mentions this window or how to get there. Heck, search all the guides, and the internet. I'm using MPLAB 8.84, which as I check is an update behind. It may have been removed in 8.89, I haven't looked.

Anyway, here is an example of one of the options it has...


And here is the result...


And if you play with it, you will find that it is very buggy, here is an example of what happens when you try and move the fill reference level of the above options to try and make it so the fill is level with logic low.


You can see that the left corner of the fill gets moved down as it should, but the right corner stays in place and mucks everything up. This reeks of a simple bug where the dev simply missed doing the calculation for the other point. Half the other features are just as buggy also. Pretty interesting. The whole menu resets after you rebuild too, which is just as odd.

In any case, there appears to be absolutely no documentation, try finding something about it on the internet or in the guides. Like I said, nothing but crickets (silence). I also have found no other way to get the waveforms filled in like the above other than with this menu. I strongly suspect it is a remnant of a possible "MPLAB 9" and it's features, that was abandon during the move to MPLAB X. If so, it may be that there needed to be a 2011-2012-2013 MPLAB 8 user guide for it to show up in any documentation.

Thinking about pestering Microchip about this, maybe get the bugs fixed or something if they would. I don't dislike the feature. It would actually be wonderful if it all worked well.

 

[()blivion]

Hummm....

I updated to 8.89 and it is still there. So it was not a mistake that got mixed into the code, or they haven't found out it's open to the public yet.

It also appears that the one bug where rebuilding after making changes in this menu reverts all the changes to default. Now any settings carry over after a build, which is good as that was really annoying the crap out of me. Also apparently this "hidden menu" has a check box that adds a button to the toolbar for accessing it's self. It's called "Properties". So it looks like it might replace the old right-click > properties menu eventually. Can't wait, I'm already making great use of the line width feature. I hope they do some workaround for weak pull-ups too. That would be something.

Anyway, it looks like someone somewhere is tinkering with it still. I wonder if they thought no one would figure out how to access it if the hid it like they did?

EDIT: The reset bug is NOT actually fixed. Turns out it will work without clearing it's self if you don't do single steps. If the trace of logic analyzer window gets blanked to read "no data" THEN any of the setting you made get reset.

 

[granddad]

Target device not ready for debugging...
Program and verify work OK ....
Set up ... Pickit 3 FW ver 01.35.16 MPLABX v2.30... XC16 v1.24 >>> dsPIC33EV256GM102 ( External 5v powered 28 PIN dev board ( I never PK3 power ))
Check correct PGED PGEC numbers in CONFIG bits ICS = PGDx and turn off brown out . BORENO = OFF . also FWDTEN = OFF may help.

 

[BobW]

I just encountered a problem with MPLAB-X and MPASM 5.71 when dealing with macros. In my current project, I have 6 nearly identical macro definitions, and one of them was continuously showing an error when I tried to build the project. Couldn't figure out why. Lots of head scratching. Finally figured out that it wasn't the macro definition; it was a macro call elsewhere in the program. Further down in the program, I had called that macro and made a typo in one of the parameters. Instead of flagging the line with the erroneous macro call, it flagged the line with the macro definition, and gave an unintelligible error message.

So, if you get a message indicating an error in a macro definition, and you can't see any errors in it, then check all of the places where you call that macro, to see if there's an error there.

 

[Pommie]

Just wasted a couple of hours tracking down a bug which turned out to be a typo/mplabx bugget. In the 12F1840 data sheet there is a sfr called SPBRG to set baud rate. Long story short, I just couldn't communicate with a bluetooth module. After checking everything I eventually got my scope on the problem. What should have been 9,600 baud was around 100,000 baud. Checked the SFR and discover that SPBRG contains 64 instead of 832 and is also called SP1BRG - SPBRG doesn't exist but MPLABX didn't report it as an error!!

This is what the disassembly looked like,

!    SPBRG=832;             //setup for 9600 baud
0x69: MOVLW 0x40
0x6A: MOVWF PR2

Go figure.

Mike.

 

[Ian Rogers]

SPBRG is part of a 16 bit reg... SPBRGL and SPBRGH So 64 in SPBRG is correct with 3 in SPBRGH

SPBRG = 0x40;
SPBRGH = 0x3;

 

[Pommie]

For 16 bit variables they have the low and high values and a combined 16 bit value. However, in this case the error was that xc8 accepted SPBRG as used in the datasheet but the name required was SP1BRG. The attached screenshot shows what I mean.

The above compiles even though SPBRG isn't defined anywhere (edit, well not by me).

Mike.

 

[Nigel Goodwin]

The above compiles even though SPBRG isn't defined anywhere (edit, well not by me).

You've obviously got it defined somewhere?

You should be able to track it down?.

 

[nigel wright]

Beware with PIC C18 compiler the for statement doesn't work.
I fell foul of this.
So I just use while statements instead.

 

[Ian Rogers]

Beware with PIC C18 compiler the for statement doesn't work.

I've been using it for years without issue... What version are you using...

 

[nigel wright]

I've been using it for years without issue... What version are you using...

MCC18 v3.47

 

[Ian Rogers]

Wow!! Are you sure... There isn't a version 3.47.. I stopped at C18 v3.43.. Any newer chips and I use XC8..

Very little difference between v3.43 and v3.46 so I didn't bother!

 

[nigel wright]

Wow!! Are you sure... There isn't a version 3.47.. I stopped at C18 v3.43.. Any newer chips and I use XC8..

Very little difference between v3.43 and v3.46 so I didn't bother!

Language tool versions: mpasmwin.exe v5.54, mplink.exe v5.00, mcc18.exe v3.47, mplib.exe v5.00