ATN timing for generic devices?

[sparxfly]

I am attempting to download to a generic ATmega328P.
I created a boot file with appropriate configs and downloaded the bootloader to the cpu using my AVRISP2- it verfied OK.
Fuses set and verfied OK.
But target bootloader won't respond to the ATN signal when trying to download from the IDE.

APP note 101 says the ATN should be

at least 4 times at intervals of between 60mS and 90mS. The minimum pulse width for either phase of the DTR signal is 25uS

The max settings in the IDE serial port options box are 25mS period, 10% duty cycle.
On the DTR line I am seeing 6 positive going pulses at 27mS intervals of 2.8mS duration, giving 5v/0v RST pulses same interval and 400uS duration.

It seems the available IDE settings do not cover the recommended range.

[dkinzer]

But target bootloader won't respond to the ATN signal when trying to download from the IDE.

If you'd zip up the various files so that I can reproduce exactly what you're doing, I'll take a look at it.

[sparxfly]

If you'd zip up the various files so that I can reproduce exactly what you're doing, I'll take a look at it.

Thansk Don, but hold fire a mo- I am making some progress.
It appears the IDE ATN timing, while out of spec, may be working.
From some info on the forum I checked boot file size with checkboot.awk, which reported 982 bytes.
So I set the fuse options for 512words (3E00) and BOOTRST to 0 (programmed).

The target now generally responds to ATN and download begins, but hangs after about "...."
I will spend some time checking out the quality and timing or TX and RX.

[sparxfly]

I will spend some time checking out the quality and timing or TX and RX.

You can rest Don.
Looks like with xtal tolerances I am pushing it to download at 115200.
One module couldn't progress beyond device ID request, a second one completed about 30% of the time.
I will reconfigure the bootloader and IDE for a more sane download speed.

[sparxfly]

Still intermittent across download speeds from 9600 up to 230400, with little difference.
Progress varies from a few ...s to 100%, and any fail shows

Device reports a timeout waiting for data.

I can't see a parameter in any options files to tweak that timeout-
I presume it is the bootloader reporting timeout, so deep in the bootloader code?

[sparxfly]

Some further info Don-

At 19200 the timeout message appears before the target % character is received.
Debug window shows

Downloading file "C:\Users\sparxfly\Dropbox\vipra\vipra v2.zxb":
.
Device reports a timeout waiting for data.
%

It looks like the timeout is IDE generated, not the target hardware?
Must be able to tweak that value if I can find it!

[dkinzer]

Device reports a timeout waiting for data.

As a test, I copied the files from the zboot subdirectory of the ZBasic installation directory to a temporary directory and edited the file makeboot.bat so that it would build a bootloader for a 16MHz mega328P. As you observed, the resulting bootloader was 982 bytes. Next, I took a blank mega328P and put it in a prototyping board using the 28 pin ZX interface board to supply the serial interface, ATN circuit and 16MHz crystal. I also wired up the ISP SPI signals (+5, gnd, MOSI, MISO, SCK, reset) to a 6-pin header compatible with my device programmer, an Atmel AVRISP.

Using the AVRISP, I set the fuses (ext=FD, hi=D4, lo=D7) and Flashed the
atmega328P_boot.hex file built as described above. Both operations were verified by readback. I then started up the ZBasic IDE with the following content in the SciTEUser.properties file:

Code: Select all

font.monospace=font:Courier New,size:10
font.comment=font:Courier New,size:10,italics
show.target.device.ATmega328P=1
auto.identify=0
target_device=ATmega328P
download.ext=zxb
debug.reset=1
debug.speed=19200
download.speed=115200
debug.comport=2
download.identify=0
download.verify=1
download.clear=1
download.quiet=0
debug.capture=1
atn.idle.positive=0
debug.port.mode=0
atn.period=10
atn.duty=1
download.use.atn.char=0
download.atn.char=4
download.change.speed.atn.char=1

With that configuration, I compiled this program:

Code: Select all

Option DeviceParameter package "PDIP-28"
Option DeviceParameter clockFrequency 16000000
Option DeviceParameter rtcFrequency 500
Option DeviceParameter rtcScale 1
Option DeviceParameter swUartDivisor 8
Option DeviceParameter swUartMinSpeed 300
Option DeviceParameter swUartMaxSpeed 19200
Option DeviceParameter swUartBaseSpeed 2400
Option DeviceParameter timerSpeed1Divisor 1
Option DeviceParameter timerSpeed2Divisor 8
Option DeviceParameter ZBasicBootloader true

Option ConsoleSpeed 19200

Sub Main()
   Debug.Print "Hello, world!"
End Sub

After compilation, the program was downloaded successfully and the device responded with the expected output.

[sparxfly]

After compilation, the program was downloaded successfully and the device responded with the expected output.

Thanks for the time you have put in to have a look Don.
I finally got my system working.

Initially the best I got was with bootloader and IDE download speed set at 19200.
That was very intermittent, occasionally competing, but generally timing out somewhere through the process. Sometimes the timeout was reported before the target echoed it's "%" character.

On the assumption there was some delay in getting the response back to the IDE (target? usb/RS232 converter? Win7?), I upped the bootloader and IDE download speed to 28800. Consistently timing out.

For no other reason than at 19200 the download speed was the same as the application console speed when things were almost working, and maybe baud rates were getting changed during the download, I set the application console to match the bootloader/IDE download speed- both 28800.
BINGO!

My application setup is

Code: Select all

option targetdevice ATmega328P
Option DeviceParameter package "TQFP-32"
Option DeviceParameter clockFrequency 14745600
Option DeviceParameter rtcFrequency 200
Option DeviceParameter rtcScale 1
Option DeviceParameter swUartDivisor 64
Option DeviceParameter swUartMinSpeed 19200
Option DeviceParameter swUartMaxSpeed 19200
Option DeviceParameter swUartBaseSpeed 0
Option DeviceParameter timerSpeed1Divisor 1
Option DeviceParameter timerSpeed2Divisor 8
Option DeviceParameter ZBasicBootloader true

option consolespeed 28800
option rtc on
option signon on
option txqueuesize 100
option rxqueuesize 40
option console com1

I still don't understand why, but I can live with it.

[sparxfly]

Must say Don, that despite the issues with download (that I suspect may be more related to Win7?), the transition from ZX to native mode was absolutely painless- just added the required options, and away it went! So I can happily go into production.

One thing I have noticed (which is almost certainly a Win 7 issue), using the debug panel to capture serial output, it does not capture when that window loses focus. I have to stay with the ZBasic IDE in focus.

[dkinzer]

[...] the debug panel to capture serial output, [...] does not capture when that window loses focus.

I don't see this. As I am typing (on a Win 7 system) this I'm watching new output appear in the debug window of the IDE.

The max settings in the IDE serial port options box are 25mS period, 10% duty cycle. It seems the available IDE settings do not cover the recommended range.

It is true that the period is currently limited to 25mS while the duty cycle range is 1% to 99%. An upcoming release of the IDE has a higher maximum period - 175mS. I'll have to recheck the range mentioned in the app note. Looking at it now, I think the low end is incorrect. The actual minimum that will work for a particular device depends on the clock startup configuration (controlled by fuse settings). The maximum period for a particular device is the minimum period plus a fixed amount that is controlled by a constant in the bootloader code (ATN_RESET_DELAY_2 defined in zboot.h).

[sparxfly]

As I am typing (on a Win 7 system) this I'm watching new output appear in the debug window of the IDE..

Must be something particular about my system and USB drivers. But not to worry, it does all I need, and I can work around the odd behaviour.