AVR Freaks

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

Posted by newbie123: Fri. May 1, 2020 - 08:10 PM

Hi Guys,

I am hoping someone can help me.

I am programming a very small file into an atmega328pb.

The program is only to test each pin to ensure the board connections are good after

soldering the atmega328pb (QFN) to the board with a modded toaster oven.

The board is a very small castellated board with an atmega328pb in a QFN package.

I built a castellated board adapter to plug in the small board before it is installed on the main board.

Just for the record, I am not programming the fuses and this is not a fuse problem.

Before any soldering has taken place, I take a virgin m328pb (with factory fuses)

and insert it into a QFN adapter board with an ISP connector and it's own crystal

or without the crystal, depending on the fuses.

I can program the fuses or leave them factory, this isn't the problem.

If I want to use the crystal on my test board, the fuses values I am using are:

FuseL: 0xF7, FuseH: 0xDF, FuseExt: 0xF7.

I can program any code into the atmega328pb and it works.

If I program this code (see below) into the atmega328pb, the ISP programming no longer works.

I then have to put the QFN adapter in my parallel programmer to erase the atmega328pb

(because the code is doing something to prevent ISP from working).

I am using the adapter to ensure something doesn't go wrong before I solder the QFN device to the board,

because then it's impossible to fix when you can't use ISP programming!

Reading the chip with the parallel programmer i can see that the fuses have not changed,

however the chip is undetectable in ISP mode with this code installed which is why I have to erase it in parallel mode.

ISP is restored once the chip is erased.

Any other code I have programmed is working, and does not prevent ISP from working.

I can erase and program the device numerous times without problems.

I am not using PB6 & PB7 (xtal1 & xtal2) nor am I using PC6 in my code.

(RSTDISBL is not programmed.)

this is the code I am using:

;
;Simple program to test castellated board connections
;after m328pb QFN installation
;
.nolist
.include "m328pbdef.inc"
.list
;
;***********************************************************
;for long delays
.def	dcount  =r5
.def	dcount2 =r6
.def	dcount3 =r7
.def	dcount4 = r8
;
.def	count = r15
.def	temp  = r16
;
;program fuses atmega328pb:
;low:  0xF7
;high: 0xDF
;ext:  0xF7
;---------------------------------------------------------
.org 0
	jmp    Start      ;

Start:
	ldi	temp,LOW(RAMEND)	;set up stack pointer
	out	SPL,temp
	ldi	temp,HIGH(RAMEND)
	out	SPH,temp

	ldi	temp,0b00111111	;PORTB LED's OFF.
	out	PORTB, temp      	;
	ldi	temp,0b00111111	;PB0 - PB5 = output
	out	DDRB,temp

	ldi	temp,0b00111111	;PORTC LED's OFF.
	out	PORTC, temp      	;
	ldi	temp,0b00111111	;PC0 - PC5 = output
	out	DDRC,temp

	ldi	temp, 0b01111111	;PORTD LED's OFF
	out	PORTD, temp      	;PD5, PD7 not used
	ldi	temp, 0b01111111	;PD0 - PD6 = output
	out	DDRD,temp

	ldi	temp, 0b00001100	;PE2, PE3 LED's OFF
	out	PORTE, temp      	;
	ldi	temp, 0b00001100	;PE2, PE3 = output
	out	DDRE,temp

	ldi	temp,2		;do it twice
	mov	count,temp
Main:
;First do PORTD
	cbi 	PORTD,PORTD0	;PD0 LED ON		;1
	rcall	Delay1S
	sbi 	PORTD,PORTD0	;PD0 LED OFF

	cbi 	PORTD,PORTD1	;PD1 LED ON		;2
	rcall	Delay1S
	sbi 	PORTD,PORTD1	;PD1 LED OFF

	cbi 	PORTD,PORTD2	;PD2 LED ON		;4
	rcall	Delay1S
	sbi 	PORTD,PORTD2	;PD2 LED OFF

	cbi 	PORTD,PORTD3	;PD3 LED ON		;6
	rcall	Delay1S
	sbi 	PORTD,PORTD3	;PD3 LED OFF

	cbi 	PORTD,PORTD4	;PD4 LED ON		;8
	rcall	Delay1S
	sbi 	PORTD,PORTD4	;PD4 LED OFF

;skip PD5 (unused PIN)

	cbi 	PORTD,PORTD6	;PD6 LED ON		;10
	rcall	Delay1S
	sbi 	PORTD,PORTD6	;PD6 LED OFF

Main1:
;Now do PORTB
	cbi 	PORTB,PORTB0	;PB0 LED ON		;12
	rcall	Delay1S
	sbi 	PORTB,PORTB0	;PB0 LED OFF

	cbi 	PORTB,PORTB1	;PB1 LED ON		;14
	rcall	Delay1S
	sbi 	PORTB,PORTB1	;PB1 LED OFF

	cbi 	PORTB,PORTB2	;PB2 LED ON		;16
	rcall	Delay1S
	sbi 	PORTB,PORTB2	;PB2 LED OFF

	cbi 	PORTB,PORTB3	;PB3 LED ON		;18
	rcall	Delay1S
	sbi 	PORTB,PORTB3	;PB3 LED OFF

	cbi 	PORTB,PORTB4	;PB4 LED ON		;20
	rcall	Delay1S
	sbi 	PORTB,PORTB4	;PB4 LED OFF

	cbi 	PORTB,PORTB5	;PB5 LED ON		;22
	rcall	Delay1S
	sbi 	PORTB,PORTB5	;PB5 LED OFF

Main2:
;Now do PORTE
	cbi	PORTE,PORTE2	;PE2 LED ON		;24
	rcall	Delay1S
	sbi	PORTE,PORTE2	;PE2 LED OFF

	cbi	PORTE,PORTE3	;PE3 LED ON		;26
	rcall	Delay1S
	sbi	PORTE,PORTE3	;PE3 LED OFF

Main3:
;Now do PORTC
	cbi 	PORTC,PORTC0	;PC0 LED ON		;28
	rcall	Delay1S
	sbi 	PORTC,PORTC0	;PC0 LED OFF

	cbi 	PORTC,PORTC1	;PC1 LED ON		;30
	rcall	Delay1S
	sbi 	PORTC,PORTC1	;PC1 LED OFF

	cbi 	PORTC,PORTC2	;PC2 LED ON		;32
	rcall	Delay1S
	sbi 	PORTC,PORTC2	;PC2 LED OFF

	cbi 	PORTC,PORTC3	;PC3 LED ON		;34
	rcall	Delay1S
	sbi 	PORTC,PORTC3	;PC3 LED OFF

	cbi 	PORTC,PORTC4	;PC4 LED ON		;36
	rcall	Delay1S
	sbi 	PORTC,PORTC4	;PC4 LED OFF

	cbi 	PORTC,PORTC5	;PC5 LED ON		;38
	rcall	Delay1S
	sbi 	PORTC,PORTC5	;PC5 LED OFF

	dec count
	brne	loop

stop:
	rjmp	stop

loop:
	rjmp	main
;***************************************************************
.equ     XTAL = 1000          ;use internal clock & stock fuses
;.equ     XTAL = 4000          ;use 4MHz crystal with above fuse settings
;
delay:    
    ldi    temp,40
    mov    dcount3,temp
dl2:
    ldi    temp,(XTAL/120)    ;XTAL is found in uart.inc
    mov    dcount2,temp
dl1:
    dec    dcount2
    brne    dl1

    dec    dcount3
    brne    dl2

    dec    dcount
    brne    delay
    ret
;***************************************************************
Delay250ms:
    ldi    temp,250        ; delay 250mS
    mov    dcount,temp
    call    delay
    ret
;***************************************************************
Delay1S:
    ldi    temp,4        ; delay 1 Second
    mov    dcount4,temp
Del1S:
    call    Delay250ms
    dec    dcount4
    brne    Del1S
    ret
;***************************************************************
.exit

This topic has a solution. Jump to the solution.

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, solved, STK500, Pololu, atmega328pb

Last Edited: Mon. May 4, 2020 - 06:14 PM

https://www.avrfreaks.net/forum/programming-atmega328pb-ispenterprogmode-fail

Level: Raving Lunatic

Joined: Wed. Jun 30, 2004

Posts: 6582 View posts

Location: Cincinnati Oh

Posted by avrcandies: Fri. May 1, 2020 - 09:32 PM

See post 43 here...looks like you were previously part of this posting

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 30146 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

Posted by js: Fri. May 1, 2020 - 09:34 PM

You are using the ISP pins with LEDs, what is the value of the series resistors to the LEDs?

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

Posted by newbie123: Fri. May 1, 2020 - 10:36 PM (Reply to #3)

js wrote:

You are using the ISP pins with LEDs, what is the value of the series resistors to the LEDs?

no i am not.

presently i am testing the chip in a socket like this one:

adapter link

The socket is plugged into an ISP breakout board with some bypoass caps and an ISP connector, nothing else.

When i do have the chip soldered on the board, yes there is a 470 ohm resistor to each led.

This code worked before on a few other atmega328pb. Maybe I have some bad m328pb?

The code shouldn't mess up the ISP programming, am I missing something?

If you want to test this code on an atmega328pb the compiled hex is here:

:020000020000FC
:100000000C9402000FEF0DBF08E00EBF289A299A4A
:100010002A9A2B9A2C9A2D9A209A219A229A239ADC
:10002000249A259A409A419A429A439A449A459A28
:10003000389A399A3A9A3B9A3C9A3D9A0FE70BB90B
:100040000FE70AB9729A739A6A9A6B9A0AE0F02ECD
:1000500058984ED0589A59984BD0599A5A9848D097
:100060005A9A5B9845D05B9A5C9842D05C9A5E98AD
:100070003FD05E9A28983CD0289A299839D0299A5E
:100080002A9836D02A9A2B9833D02B9A2C9830D095
:100090002C9A2D982DD02D9A72982AD0729A7398F6
:1000A00027D0739A409824D0409A419821D0419A01
:1000B00042981ED0429A43981BD0439A449818D035
:1000C000449A459815D0459AFA9409F4FFCFC0CFC9
:1000D00008E2702E01E2602E6A94F1F77A94D1F76B
:1000E0005A94B1F708950AEF502E0E9468000895BF
:0E00F00004E0802E0E9473008A94E1F70895C8
:00000001FF

If you program an atmega328pb with this code, be sure you have a parallel programmer available to erase it

or you could be locked out!

edit: the chip must be an atmega328PB. The atmega328 or atmega328P does not have this problem (and they don't have PE2, and PE3)

Last Edited: Fri. May 1, 2020 - 10:48 PM

https://www.ampertronics.com.au

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

Posted by newbie123: Fri. May 1, 2020 - 10:43 PM

avrcandies wrote:

See post 43 here...looks like you were previously part of this posting

https://www.avrfreaks.net/forum/programming-atmega328pb-ispenterprogmode-fail

obviously you didn't read my post. I mentioned that this is not a fuse programming problem.

The problem is only present when the above code is programmed in the mcu.

Any other code does not present this problem.

in order to troubleshoot, there are no components, except 100nF bypass cap on VCC and GND, and AVCC, GND, and an ISP connector,

and it all works (ISP doesn't get disabled) unless the above hex file is programmed in the m328pb.

An atmega328 or atmega328p does not have these problems with the above hex file.

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 30146 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

Posted by js: Fri. May 1, 2020 - 10:52 PM

I don't have a PB chip to test. However when the chip is being programmed the code will not run as the reset line is asserted so can't be the code.

Do you have a good connection to the reset line? No caps or anything else on that?

When you use the parallel programmed to read the fuses check the dW fuse just in case it gets set somehow.

John Samperi

Ampertronics Pty. Ltd.

* Electronic Design * Custom Products * Contract Assembly

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

Posted by newbie123: Fri. May 1, 2020 - 11:13 PM (Reply to #6)

js wrote:

Do you have a good connection to the reset line? No caps or anything else on that?

yes. nothing. As I mentioned, other code runs and doesn't disable ISP.

js wrote:

When you use the parallel programmed to read the fuses check the dW fuse just in case it gets set somehow.

No fuses were changed and the fuses read back with the parallel programmer.

The hex file programs and verifies, however once the chip is reset, or you try to read or program it again,

ISP disabled.

Just for a test I used my avrdragon and avrstudio7.

Same thing. Only this code disables ISP.

I hope someone can try this code so I don't think I am losing my mind!

Level: Raving Lunatic

Joined: Wed. Jun 30, 2004

Posts: 6582 View posts

Location: Cincinnati Oh

Posted by avrcandies: Fri. May 1, 2020 - 11:14 PM

The problem is only present when the above code is programmed in the mcu.

Any other code does not present this problem.

I am simply referring to this statement #43, which sounds like possibly what you might have encountered, maybe you suffer the same fate!

I thought it was just me! Mega328PB seems to program, but it runs at the wrong speed then it refuses to connect to the programmer again.

====================

A suggestion:

Have you tried removing parts of your failing program? Remove the last 90%...does it still work...add some more...does it still work..add some more....eventually you will find the spot where it doesn't work.

You could also have your isp miswired. Example: instead of wiring to gnd you wire to some IO that is "almost gnd" and still manages to still program, but then the program does something to the pin & now it is no longer "almost gnbd"" and thus wont program.

Please show your ISP hookup.

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!

Last Edited: Fri. May 1, 2020 - 11:27 PM

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

Posted by newbie123: Fri. May 1, 2020 - 11:25 PM (Reply to #8)

avrcandies wrote:

Have you tried removing parts of your failing program? Remove the last 90%...does it still work...add some more...does it still work..add some more....eventually you will find the spot where it doesn't work.

thanks for responding.

the program is simple, i don't see what i can remove.

I did try to set the individual pins instead of writing a value to the entire port or DDRB.

I was thinking that setting or clearing PB6, PB7 may have had an effect on the xtal1, or xtal2 pins since they are the same.

Tried the same thing with PC6 (reset), shouldn't have to do this because RSTDISBL is not programmed and the program doesn't use PC6 or PB6, PB7.

The fact that this code doesn't cause the same problems in the atmega328P is a mystery.

Maybe the problem is something to do with PORTE that I am not familiar with as the other m328's don't have these pins.

Level: Raving Lunatic

Joined: Wed. Jun 30, 2004

Posts: 6582 View posts

Location: Cincinnati Oh

#10

Posted by avrcandies: Fri. May 1, 2020 - 11:31 PM

i don't see what i can remove.

what are you talking about?? Does this much does it still work?

YES??---Then do more...keep adding on until it stops working, you already know if you keep adding on it quits

NO??---then remove some & find out where it conks out

also, I already added another idea to the end of post 8

Start:
	ldi	temp,LOW(RAMEND)	;set up stack pointer
	out	SPL,temp
	ldi	temp,HIGH(RAMEND)
	out	SPH,temp

	ldi	temp,0b00111111	;PORTB LED's OFF.
	out	PORTB, temp      	;
	ldi	temp,0b00111111	;PB0 - PB5 = output
	out	DDRB,temp

	ldi	temp,0b00111111	;PORTC LED's OFF.
	out	PORTC, temp      	;
	ldi	temp,0b00111111	;PC0 - PC5 = output
	out	DDRC,temp

	ldi	temp, 0b01111111	;PORTD LED's OFF
	out	PORTD, temp      	;PD5, PD7 not used
	ldi	temp, 0b01111111	;PD0 - PD6 = output
	out	DDRD,temp

	ldi	temp, 0b00001100	;PE2, PE3 LED's OFF
	out	PORTE, temp      	;
	ldi	temp, 0b00001100	;PE2, PE3 = output
	out	DDRE,temp

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!

Last Edited: Fri. May 1, 2020 - 11:33 PM

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

#11

Posted by newbie123: Fri. May 1, 2020 - 11:33 PM

avrcandies wrote:

You could also have your isp miswired. Example: instead of wiring to gnd you wire to some IO that is "almost gnd" and still manages to still program, but then the program does something to the pin & now it is no longer "almost gnbd"" and thus wont program.

I have checked and triple checked the ISP connection and every single pin.

Again it does work with other code (just not this code) so my hardware is not the issue.

Level: Raving Lunatic

Joined: Wed. Jun 30, 2004

Posts: 6582 View posts

Location: Cincinnati Oh

#12

Posted by avrcandies: Fri. May 1, 2020 - 11:36 PM (Reply to #11)

Start whittling away your code, and you will find it. Since it is painful to recover, you have to instead start with a few lines & build up. You already know it will soon fail & after a few additions you will quickly find it.

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!

Last Edited: Fri. May 1, 2020 - 11:52 PM

Level: Raving Lunatic

Joined: Mon. Oct 7, 2002

Posts: 7361 View posts

Location: Denmark

#13

Posted by sparrow2: Sat. May 2, 2020 - 09:23 AM

Just to make it clear I don't know if it's your problem , a 328pb is NOT plugin replacement for a 328(p) the pin layout is different.

So if you use the same board now there will be port pins where some of the old gnd and vcc was.

And the other way round if you have a 328 board that only feed on some of the vcc's perhaps your 328pb don't get real vcc (but a tad from IO's you hold high)

Level: Raving Lunatic

Joined: Thu. Oct 18, 2001

Posts: 5479 View posts

Location: Eastern England.

#14

Posted by Brian Fairchild: Sat. May 2, 2020 - 10:26 AM

newbie123 wrote:

FuseL: 0xF7, FuseH: 0xDF, FuseExt: 0xF7.

Are you sure about your fuses values?

The datasheet has this...

...no sign of 0111 in the lower bits of the low fuse.

There used to be an entry for that in the early datasheets before they removed the full-swing oscillator option...

...but that's from an old datasheet and doesn't apply to current chips.

BTW...I tested you hex file on a 328PB and I have no problems continuing to access the chip.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Last Edited: Sat. May 2, 2020 - 10:28 AM

Engbedded Avr Fuse Calculator

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

#15

Posted by newbie123: Sun. May 3, 2020 - 04:02 PM

Brian Fairchild wrote:

Are you sure about your fuses values?

Yes. The chip will not work when I select Ext Low Freq Crystal.

I tried all the values FuseL: 0xE4 all the way up to 0xE5

It doesn't work with my 4 MHz crystal and two 22pF caps.

Instantly after programming this fuse value, it's undetectable.

I did get it to work using External Crystal Osc 3 - 8 MHz

and the fuse values I mentioned before have been working in the circuit

since December.

Fuse values here:

Brian Fairchild wrote:

BTW...I tested you hex file on a 328PB and I have no problems continuing to access the chip.

Thank you for taking the time to do this for me!

I don't know what's going on, it's not the fuses. It's not the hardware.

I have tried programming lots of test hex files and they do not cause problems

like the code posted above.

After programming the above code, try to detect the chip fails every time in ISP mode.

As soon as the chip is erased with parallel mode, it is detectable again in ISP mode.

Before programming, chip is working in ISP mode.

Programmed and verified Test code

Now try to read signature bytes, FAILED!

Read Fuses in parallel mode, Fuses haven't changed.

Erase the m328pb using parallel mode. I am using atmega168 because my programmer doesn't support m328.

This is not an issue, the parallel mode commands and pinout are the same on both chips.

Detected again in ISP mode after erasing code in parallel mode.

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

#16

Posted by newbie123: Sun. May 3, 2020 - 04:24 PM

sparrow2 wrote:

Just to make it clear I don't know if it's your problem , a 328pb is NOT plugin replacement for a 328(p) the pin layout is different.

So if you use the same board now there will be port pins where some of the old gnd and vcc was.

And the other way round if you have a 328 board that only feed on some of the vcc's perhaps your 328pb don't get real vcc (but a tad from IO's you hold high)

Thanks but this is not the problem. I am well aware of the differences in pinouts between the two devices.

My board uses PE2 & PE3 (pins 19 & 22) and PE0 and PE1 (pins 3 & 6) are not connected on my board.

The board works. (I have two boards working since December)

Besides, I am not using my board. I haven't gotten there yet.

I am using a QFN32 to DIP32 adapter as mentioned above.

Look for the ebay link above and you will see a picture of the adapter.

I am doing this to load my test code in case the chip is undetectable afterwards, this way I can fix it with the parallel mode.

If I cannot access the chip in ISP mode when it is soldered on the board, well then its a big headache to try and remove the QFN device.

Not testing the circuit is not an option because the ground pad under the chip can be shorted to one of the pins.

I have taken careful steps in soldering the QFN device particularly ensuring that the ground pad does not have too much paste.

Regardless, that is the reason for the test code.

The board is a SOIC28 replacement. Basically I am removing the 28pin soic

device and installing my castellated board in it's place with the atmega328pb to run the circuit.

Once the chip is soldered on the board, I plug the board into a test socket connected to a bunch of led's.

If the led is on all the time, there is a short to the GND pad under the chip.

If the led's go in sequence, everything is fine and then I solder the board to the main board.

The only problem is accessing the chip in ISP mode (in the adapter) after the test code is loaded.

I have managed to do a few back in December that were tested and working.

Level: Raving Lunatic

Joined: Thu. Oct 18, 2001

Posts: 5479 View posts

Location: Eastern England.

#17

Posted by Brian Fairchild: Sun. May 3, 2020 - 07:08 PM

newbie123 wrote:

Brian Fairchild wrote:

Are you sure about your fuses values?

Yes. ...

Fuse values here: Engbedded Avr Fuse Calculator

Care to show me where on that site they show the fuses for a 328PB?

You seem to have ignored the tables from the datasheets I showed.

The 328PB is a different chip to the 328P

328PB datasheet... http://ww1.microchip.com/downloa...

328P datasheet... http://ww1.microchip.com/downloa...

And see this app note entitled " Differences between ATmega328/P and ATmega328PB" ... http://www.microchip.com//wwwApp...

In particular the app note says...

" ATmega328PB is not a drop-in replacement for ATmega328 variants, but a new device."

One major difference is in the clock options.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Level: Raving Lunatic

Joined: Wed. Jun 30, 2004

Posts: 6582 View posts

Location: Cincinnati Oh

#18

Posted by avrcandies: Sun. May 3, 2020 - 08:24 PM

I mentioned that this is not a fuse programming problem.

The problem is only present when the above code is programmed in the mcu.

Any other code does not present this problem.

Then, have you tried burning the code line by line, adding more and more until it quits working? Since the code is <150 asm lines that will quickly & easily pinpoint the issue, or show that it is something else entirely. Maybe it will uncover some intermittent shorting (maybe an io shorted to a clocking pin).

BTW...I tested you hex file on a 328PB and I have no problems continuing to access the chip.

Brian's testing suggests it's thus an interact between something in your code and your specific hardware wiring/chip configuration or soldering

I did try to set the individual pins instead of writing a value to the entire port or DDRB.

I was thinking that setting or clearing PB6, PB7 may have had an effect on the xtal1, or xtal2 pins since they are the same.

Tried the same thing with PC6 (reset), shouldn't have to do this because RSTDISBL is not programmed and the program doesn't use PC6 or PB6, PB7.

Don't change the code, you might accidentally "fix" it...keep it in the form that you know fails and find out where it goes south.

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!

Last Edited: Sun. May 3, 2020 - 08:41 PM

https://www.vagrearg.eu/atpack/atpack.html

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

#19

Posted by newbie123: Sun. May 3, 2020 - 09:14 PM (Reply to #17)

Brian Fairchild wrote:

Care to show me where on that site they show the fuses for a 328PB?

You seem to have ignored the tables from the datasheets I showed.

That fuse calculator webpage doesn't support the new PB device.

I found a new one that supports the atmega328pb here:

You are right about the fuses, but the fuse values for full swing oscillator have worked for the last 4 months.

The difference datasheet does not mention any difference in fuses from the atmega328 & variants to the atmega328pb

EXCEPT:

Clock source options of the ATmega328 variants include full swing crystal oscillator, which can be
selected by configuring the flash fuse. However, in the new ATmega328PB, the full swing crystal oscillator
is removed.

And of course the CFD fuse.

Anyway, It isn't a fuse problem.

I found the problem, just no solution yet.

Please read the next post.

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

#20

Posted by newbie123: Sun. May 3, 2020 - 09:35 PM

avrcandies wrote:

Then, have you tried burning the code line by line, adding more and more until it quits working? Since the code is <150 asm lines that will quickly & easily pinpoint the issue, or show that it is something else entirely. Maybe it will uncover some intermittent shorting (maybe an io shorted to a clocking pin).

Thanks again for responding to my post.

I didn't think I had to do this because of the simplicity of the code

but here is the cause of the problem:

When setting up DDRB and PORTB, the xtal1 and xtal2 pins are using PB6 and PB7 if the fuses

for the internal osc are programmed.

When I remove this code it works:

	ldi	temp,0b00111111	;PORTB LED's OFF.
	out	PORTB, temp      	;
	ldi	temp,0b00111111	;PB0 - PB5 = output
	out	DDRB,temp

But this doesn't help me because I need to use all of PORTB.

So I tried this:

	in	temp, PORTB
	ori	temp,0b00111111	        ;PB0 - PB5 = high
	out	PORTB,temp		;leave PB6, PB7 alone!

	in	temp,DDRB
	ori	temp,0b00111111	        ;PB0 - PB5 = output
	out	DDRB,temp		;leave PB6, PB7 alone!

Still no good. I can program the code into the m328pb, but it disables ISP capability.

When I use the parallel mode to erase the code the chip works in ISP mode again.

Must be something to do with xtal1 and xtal2, because parallel mode provides its own clock.

This is why I need parallel mode to erase the chip.

I have looked at the datasheet to see if there is something about PORTB I have missed, but i came up with nothing.

This shouldn't be an issue because I am using these fuse values:

Anyways it shouldn't matter because the device is in reset when programming in ISP mode.

The reset pin on the ISP connector is directly connected to the atmega328pb, no pullups, no capacitors,

nothing else connected to the reset line. Same thing with the 3 ISP lines, MOSI, MISO, and SCK.

Direct connection to the chip from the ISP connector.

The 4MHz crystal connected to XTAL1, XTAL2 with two 22pF capacitors to gnd.

I am lost.

Last Edited: Sun. May 3, 2020 - 09:59 PM

Level: Raving Lunatic

Joined: Wed. Jun 30, 2004

Posts: 6582 View posts

Location: Cincinnati Oh

#21

Posted by avrcandies: Sun. May 3, 2020 - 10:19 PM

Well at least you have narrowed it down quite a bit!! So we know it seems to revolve around the crystal pins/clocking

Anyways it shouldn't matter because the device is in reset when programming in ISP mode.

Yes, You'd think so (as long as it has a valid clock). Unless fiddling with those pins, gets it into some catch-22 situation?? Now Brian had working results with that exact code...soooo what can differ in regard to all of this?

Just to be clear---does everything (your "bad code" ) keep working/programming fine if you stick with the internal RC clock?

Here's a far-fetched thought: If you set the chip to use an ext xtal, then those xtal pins should be 100% taken over by the xtal & ignore any fiddling with ddrb, portb, etc. But what if there is a flaw or errata, where if you set ext xtal AND try to set up those pins as a port? Maybe it falls flat on its face, kills the clock & then, of course, no more programming can take place. If your code always blinks an led you can see if it is still running (I didn't look at your code to see if it does).

I'm not sure if Brian was using an ext xtal or not

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!

Last Edited: Sun. May 3, 2020 - 10:55 PM

ki0bk

Level: Raving Lunatic

Joined: Mon. Sep 8, 2014

Posts: 8821 View posts

Location: Over the rainbow

#22

Posted by ki0bk: Sun. May 3, 2020 - 10:26 PM

I find it odd you first set the port bits to enable internal pull ups, then

set the ddr reg for the same port bits to outputs???

normally one would first set direction with ddr, then set port pins high/low using port.

jim

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

#23

Posted by newbie123: Sun. May 3, 2020 - 11:01 PM (Reply to #21)

avrcandies wrote:

Just to be clear---does everything (your "bad code" ) keep working/programming fine if you stick with the internal RC clock?

The test code works. The led's flash when connected. The problem is I can't program it once this code is loaded in the m328pb.

I am not using the internal oscillator. I am using a 4MHz crystal with two 22pF caps and the fuse values Low: 0xFD High: 0xDF Ext: 0xF7

Level: Raving Lunatic

Joined: Wed. Jun 30, 2004

Posts: 6582 View posts

Location: Cincinnati Oh

#24

Posted by avrcandies: Mon. May 4, 2020 - 02:34 AM

I am not using the internal oscillator.

Ok, but does everything work properly & keep working properly (leds keep flashing) & stay ISP reprogrammable when you use the internal RC clock? That will be valuable info!

Otherwise somehow something is causing the external clock to grind to a halt (leds will then stop flashing).

Also, what if the clock failure detector option is turned on? Then leds would not stop flashing, since a backup clock (default: slow) will automatically take over.

It still doesn't explain how fiddling with the port pins gums things (clock) up.

note sure if this old info is of any use (or may already be corrected):

The latest complete datasheet (DS40001906C, dated 2018-02-22) still gives conflicting pinouts for serial ISP.

"Figure 32-6. Serial Programming and Verify, VCC = 1.8 - 5.5V" on p400 shows MOSI, MISO and SCK as PB5, PB6 and PB7 respectively. That's wrong; it appears to be copied from the datasheet for the ATmega324PB (for which those pins are correct).

For the ATmega328PB the correct pins for MOSI, MISO and SCK are PB3, PB4 and PB5 respectively. The datasheet has that correct further down the page, in "Table 32-15. Pin Mapping Serial Programming". (The schematic for the 328PB Xplained Mini board also shows the correct pins.)

Below Table 32-15 there also appears this confusing note: "The pin mapping for SPI programming is listed. Not all parts use the SPI pins dedicated for the internal SPI interface." What it means is this: The pin mapping for serial ISP is listed. There are pins dedicated for the internal SPI but not all parts use them for ISP.

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!

Last Edited: Mon. May 4, 2020 - 02:57 AM

Krupski

Level: Hangaround

Joined: Tue. Nov 17, 2015

Posts: 223 View posts

Location: NY, USA

#25

Posted by Krupski: Mon. May 4, 2020 - 04:31 AM

newbie123 wrote:

js wrote:

You are using the ISP pins with LEDs, what is the value of the series resistors to the LEDs?

no i am not.

presently i am testing the chip in a socket like this one:

adapter link

The socket is plugged into an ISP breakout board with some bypoass caps and an ISP connector, nothing else.

When i do have the chip soldered on the board, yes there is a 470 ohm resistor to each led.

This code worked before on a few other atmega328pb. Maybe I have some bad m328pb?

The code shouldn't mess up the ISP programming, am I missing something?

Only things I know of that kills ICSP programming is setting the SPIEN fuse bit to 1 or disabling the RESET pin.

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

Level: Raving Lunatic

Joined: Thu. Oct 18, 2001

Posts: 5479 View posts

Location: Eastern England.

#26

Posted by Brian Fairchild: Mon. May 4, 2020 - 07:55 AM

newbie123 wrote:

I am not using the internal oscillator. I am using a 4MHz crystal with two 22pF caps and the fuse values Low: 0xFD High: 0xDF Ext: 0xF7

Do you have some smaller caps to try?

22pF, according to the datasheet, is the absolute maximum and would include any wiring and parasitic capacitance.

If you have a plain generic crystal it might be worth trying something closer to 15pF. In any case it'll be worth checking the specs on your crystals.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

#27

Posted by newbie123: Mon. May 4, 2020 - 11:24 AM (Reply to #26)

Brian Fairchild wrote:

Do you have some smaller caps to try?

22pF, according to the datasheet, is the absolute maximum and would include any wiring and parasitic capacitance.

If you have a plain generic crystal it might be worth trying something closer to 15pF. In any case it'll be worth checking the specs on your crystals.

Thanks for the tip.

I don't have any smaller caps. The ones I am using are not from EBAY, they are from Digi-Key, as well as the crystal (I think it's a Citizen brand)

I have never had this problem before, but it's worth investigating.

Last Edited: Mon. May 4, 2020 - 11:27 AM

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

This reply has been marked as the solution. #28

Posted by newbie123: Mon. May 4, 2020 - 11:36 AM

I figured out the problem.

I can't bring PB5 (same pin as SCK) low on startup. This somehow disables ISP.

so what I have done is this:

This is the only way I can make this work.

	in	temp,DDRB
	ori	temp,0b00111111	        ;PB0 - PB5 = output
	out	DDRB,temp		;leave PB6, PB7 alone!

	in	temp, PORTB
	ori	temp,0b00011111	        ;PB0 - PB4 = high
	out	PORTB,temp		;leave PB5, PB6, PB7 alone!

;wait one second before bringing PB5 (SCK) low so ISP is not disabled
;next time the chip is programmed
;
	rcall	Delay1S
	sbi 	PORTB,PORTB5	       ;PB5 LED OFF

I can program it, and reprogram it without disabling ISP mode.

ISP sometimes fails on the first try, but retrying will usually work.

Sometimes I have to retry programming 3 or 4 times, but it does work.

Perhaps a longer delay would be better (3 - 4 seconds), but this is only test code.

I shouldn't have to do this, there must be another way or a reason why this is happening.

There is nothing connected on PB5 in the test socket.

I was under the impression that when RESET is low the pins are inputs or disabled.

Also see post #35 for programmer solution.

Last Edited: Mon. May 4, 2020 - 06:16 PM

Level: Raving Lunatic

Joined: Mon. Oct 7, 2002

Posts: 7361 View posts

Location: Denmark

#29

Posted by sparrow2: Mon. May 4, 2020 - 11:41 AM

just take the caps off.

I'm not sure how your converter is made but those longer wires will give some extra pf. (perhaps feed from a 328p board (xtal out) just verify that it's actually the problem, no fuse changes use xtal in)

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

#30

Posted by newbie123: Mon. May 4, 2020 - 11:57 AM

sparrow2 wrote:

just take the caps off.

I'm not sure how your converter is made but those longer wires will give some extra pf. (perhaps feed from a 328p board (xtal out) just verify that it's actually the problem, no fuse changes use xtal in)

Again, there are no wires.

The QFN32 to DIP32 test socket is plugged in a small breakout board that contains a 4 MHz crystal and two 22pF caps.

It also contains a 10 pin ISP connector with direct connections to the RST, MISO, MOSI and SCK pins.

I am only using the QFN32 to DIP32 test socket to find a solution to this problem because I am sick and tired of

wasting boards and chips when I can't reprogram them after using the test code posted above.

The code works fine when plugged into all the LED's on the test board.

The real problem is that I cannot reprogram it if PB5 (SCK) is high in my code.

Last Edited: Mon. May 4, 2020 - 12:00 PM

Level: Raving Lunatic

Joined: Mon. Oct 7, 2002

Posts: 7361 View posts

Location: Denmark

#31

Posted by sparrow2: Mon. May 4, 2020 - 01:52 PM

The wires is the distance to the osc!

Normally you want the xtal close (within 1 cm), I assume you add more than that with the socket.

In the old DIP days I used to solder the xtal to the osc. and place it on top of the chip. (kind of the first try of a internal osc. , and it always worked without osc. caps, the low power osc. could have problems with the caps.)

Level: Raving Lunatic

Joined: Mon. Oct 7, 2002

Posts: 7361 View posts

Location: Denmark

#32

Posted by sparrow2: Mon. May 4, 2020 - 01:56 PM

The real problem is that I cannot reprogram it if PB5 (SCK) is high in my code.

Then there is a problem with your reset!!!

add:

or you have components on the programming pins or

to low a voltage, a new chip run slower than you program it.

Last Edited: Mon. May 4, 2020 - 02:05 PM

Level: Raving Lunatic

Joined: Wed. Jun 30, 2004

Posts: 6582 View posts

Location: Cincinnati Oh

#33

Posted by avrcandies: Mon. May 4, 2020 - 04:09 PM

Again, does all work well (program/reprogram, leds keep blinking) if you use the internal 8MHz osc (with PB5 both set hi and set low)? Maybe you already tested/mentioned that in these posts?

Knowing that that situation works helps to pinpoint trouble down to the xtal or xtal circuitry itself.

Having your xtal on a different board running though "connections" could cause osc troubles, since they are somewhat sensitive leads. However, if there were osc troubles, you'd notice your led(s) flashing faster/slower, or not at all.

Always have some code that keeps led(s) blinking, so you can tell if the cock stops or changes freq.

Could there be a semi-short between the PB5 & XTAL soldering/wiring? That might cause some intermittent mayhem.

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

#34

Posted by newbie123: Mon. May 4, 2020 - 06:06 PM

avrcandies wrote:

Again, does all work well (program/reprogram, leds keep blinking) if you use the internal 8MHz osc (with PB5 both set hi and set low)? Maybe you already tested/mentioned that in these posts?

Yes i tried the internal osc and I set the fuse accordingly. It does work but I can't get back in to reprogram it without erasing the chip in parallel mode.

avrcandies wrote:

Could there be a semi-short between the PB5 & XTAL soldering/wiring? That might cause some intermittent mayhem.

I checked every pin for shorts. It's all good.

If there was a hardware problem, it would malfunction on any hex code I load into the chip. The only problem I have had is this code.

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

#35

Posted by newbie123: Mon. May 4, 2020 - 06:13 PM

I have had better luck NOT USING THE USBASP programmer and avrdude!!!

I tried an avr911 programmer with AVROSP software (better) sometimes does not work.

I tried an AVR DRAGON in both avrdude (not very reliable) and the same AVRDRAGON programmer with avrstudio.

Using AVRSTUDIO with the dragon is the most reliable.

It must have something to do with how the programmer initializes the chip, (the reset line maybe??)

Any other chip and or code is always working in all programmers. It's just this code that gave me problems.

Everything is working 100% when I use the workaround in post #28 (above).

Last Edited: Mon. May 4, 2020 - 06:14 PM

Level: Raving Lunatic

Joined: Wed. Jun 30, 2004

Posts: 6582 View posts

Location: Cincinnati Oh

#36

Posted by avrcandies: Mon. May 4, 2020 - 06:16 PM

Yes i tried the internal osc and I set the fuse accordingly. It does work but I can't get back in to reprogram it without erasing the chip in parallel mode.

Now that seems even stranger...since the same problem exists even when using the internal RC...that's important to know, but I'm grasping at straws now.

We were thinking towards trouble with the ext crystal, but not now.

Do you have more than one of these 328PB chips to try (in case it is faulty)?

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!

Last Edited: Mon. May 4, 2020 - 06:18 PM

Level: Raving Lunatic

Joined: Wed. Jun 30, 2004

Posts: 6582 View posts

Location: Cincinnati Oh

#37

Posted by avrcandies: Mon. May 4, 2020 - 06:24 PM (Reply to #35)

Well that is interesting news...as you say, hitting reset should hi-Z all the lines so the port can revert to SCK for programming...but this might take some (short) time & perhaps the programmer is a bit too fast in kicking in?

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

#38

Posted by newbie123: Mon. May 4, 2020 - 06:25 PM (Reply to #36)

avrcandies wrote:

Do you have more than one of these 328PB chips to try (in case it is faulty)?

Yes definitely.

Level: Raving Lunatic

Joined: Thu. Oct 18, 2001

Posts: 5479 View posts

Location: Eastern England.

#39

Posted by Brian Fairchild: Mon. May 4, 2020 - 06:30 PM

Hmm, perhaps this explains the issue...

Quote:

1. Power-up sequence:
Apply power between VCC and GND while RESET and SCK are set to “0”. In some systems, the
programmer cannot guarantee that SCK is held low during power-up. In this case, RESET must be
given a positive pulse of at least two CPU clock cycles duration after SCK has been set to “0”.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Level: Hangaround

Joined: Thu. May 5, 2005

Posts: 359 View posts

#40

Posted by newbie123: Mon. May 4, 2020 - 07:21 PM (Reply to #39)

avrcandies wrote:

Well that is interesting news...as you say, hitting reset should hi-Z all the lines so the port can revert to SCK for programming...but this might take some (short) time & perhaps the programmer is a bit too fast in kicking in?

Brian Fairchild wrote:

Hmm, perhaps this explains the issue...

Quote:

1. Power-up sequence:
Apply power between VCC and GND while RESET and SCK are set to “0”. In some systems, the
programmer cannot guarantee that SCK is held low during power-up. In this case, RESET must be
given a positive pulse of at least two CPU clock cycles duration after SCK has been set to “0”.

The usbasp probably needs a firmware update. I think i have the newest version from 2011 - 2012 or so.

So for this project, I will use my reliable avr911 USBprog or my dragon programmer or my old avrisp programmer.

I have searched for a better programmer, but haven't found anything.

The thing is, when the test code is cleared and the final code is loaded into the m328pb, this problem does not exist.

http://avr.2057.n7.nabble.com/config-for-atmega328pb-td23214.html

Level: Raving Lunatic

Joined: Wed. Jun 30, 2004

Posts: 6582 View posts

Location: Cincinnati Oh

#41

Posted by avrcandies: Mon. May 4, 2020 - 07:57 PM

In some systems, the programmer cannot guarantee that SCK is held low during power-up. In this case, RESET must be given a positive pulse of at least two CPU clock cycles duration after SCK has been set to “0”.

If you config the port pin as a high, then it will take longer to get low via the programmer taking it low---even if it is a microsecond or 2, maybe that is enough to mess things up. If it is low already, or high z already, (before any reset) perhaps a quicker response & no trouble?

Now in your case the chip has probably already had power for a long time (since you are reprogramming a running system).....but this might still offer some clues. Def time to update the 8year old usbasp driver/code.

EDIT:

I found this...see if it makes sense or helps...
I'm currently using mega238pb in my project.
So, I've modified avrdude.conf for this part.

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!

Last Edited: Mon. May 4, 2020 - 08:07 PM