Factory Programming Service

[Don_Kirby]

One project that I'm slowly working toward producing in small quantities does not expose the reset line in the final board layout, and I'm looking for a method to get my application into the device without it. The DTR-less download will work just fine after the first program download, but not for the first one as the ATN character is not yet set.

I'm assuming that the QFP devices ('44, '44a, '44n) are programmed at the factory using some sort of test fixture and then repackaged for delivery. If this is the case, is there the possibility to either also load a user application at the same time, or alternatively, enable the ATN character by default to allow me to load my application sans reset?

My current plan is to use a test fixture that fits the entire board. It works but it's clumsy.

-Don

[dkinzer]

s there the possibility to either also load a user application at the same time, or alternatively, enable the ATN character by default to allow me to load my application sans reset?

It is not possible to load an application for the VM mode devices during manufacturing test because the application code resides in external EEPROM. It would be possible to set the ATN character, for either VMmode or native mode devices.

[mikep]

The DTR character is stored in the device EEPROM. Potentially you also have application specific "Persistent" data that is also stored in EEPROM. So I what I think you are really talking about is two things:
1. Programming the device EEPROM (ZBasic reserved area and application area).
2. Programming the separate EEPROM (before or after soldering into your circuit). If you used a PDIP device in a socket, then this is very easy as you can move the chip from a programming fixture to the circuit.

Note that programming the device EEPROM does not need any factory help or a reset line. Your application simply checks the a flag byte in EEPROM and stores data in EEPROM if false. One of the bytes stored overwrites the flag. This is similar to the way the FirstTime() flag is used except that you cannot rely on this particular flag for your application. If you use a version number for the flag then downloading new application code with a new version flag will allows your application to update the EEPROM because the version number is different.

There is no need to understand the content of the ZBasic reserved area, just simply read the data from a known system using GetPersistent and store it into program memory using a datafile or ByteVectorData.

[Don_Kirby]

I would be using native mode devices, so the external EEPROM issue is moot.

I think setting the ATN character would be sufficient in either case although it makes sense to leave it disabled by default for most applications.


-Don

[dkinzer]

I think setting the ATN character would be sufficient

Your query got me thinking about a way to allow DTR-less downloading to factory fresh devices. As an experiment, I modified the "Hello, world" program to watch for a ctrl-D in the input queue. If it is seen, the program then enters the command mode using the undocumented procedure ZXCmdMode().

With this modified program running, I was able to download successfully without DTR. Also, with the program reloaded, I was able to set the ATN character using zload.exe. This change in the factory programming would allow end users to configure new devices with the desired ATN character and download the first program all without using the DTR line.

[mikep]

Your query got me thinking about a way to allow DTR-less downloading to factory fresh devices. As an experiment, I modified the "Hello, world" program to watch for a ctrl-D in the input queue. If it is seen, the program then enters the command mode using the undocumented procedure ZXCmdMode().

There are clearly several ways to accomplish the same thing using the ConsoleRead function. For example using a special input sequence e.g Ctrl-D, the hello world program could enter a DTR character setting routine that confirms the DTR character or allows you to cancel it.

Of course once the DTR char has been set (or not) and the first program downloaded, it is not possible to change it again unless you use a similar routine to set the character.

[Don_Kirby]

... I modified the "Hello, world" program to watch for a ctrl-D in the input queue. If it is seen, the program then enters the command mode using the undocumented procedure ZXCmdMode().

That sounds like a viable solution, as long as nothing else is inadvertently affected by the change.

Of course once the DTR char has been set (or not) and the first program downloaded, it is not possible to change it again unless you use a similar routine to set the character.

I don't think this is an issue here. As a matter of course, my application sets it's own ATN character (or at least verifies the correct value) at every boot. The application could just as easily modify the value to something else. Unless, of course, I am misunderstanding your statement.


-Don

[dkinzer]

[...] as long as nothing else is inadvertently affected by the change.

Inasmuch as it is just the sample program (Hello, world) there is not much to be concerned about, I think.

[Don_Kirby]

I agree, although I have long since learned to never make assumptions regarding the 'simple' things.

That said, are you planning on loading the new 'Hello World' application into the currently shipping devices? If so, are there any tricks or techniques required to implement the new feature?

-Don

[dkinzer]

That said, are you planning on loading the new 'Hello World' application into the currently shipping devices?

That is the plan. It will likely begin to be used by the first of next week.

If so, are there any tricks or techniques required to implement the new feature?

From the end user's perspective, nothing will have changed except that the ZX will respond properly to the DTR-less downloading protocol with the ATN character being &H04. Of course, this will only be the case for the first download unless the downloaded program also responds in the same manner to receiving &H04 or sets the value of the ATN character directly (Persistent memory address &H13). An updated zload.exe is needed if you want to use it to set the ATN character while using &H04 as the ATN character. The current version erroneously ignores the ATN character specification when writing configuratioin data.

[dlh]

I think setting the ATN character would be sufficient

Your query got me thinking about a way to allow DTR-less downloading to factory fresh devices. As an experiment, I modified the "Hello, world" program to watch for a ctrl-D in the input queue. If it is seen, the program then enters the command mode using the undocumented procedure ZXCmdMode().

Will you publish the code for the modified "Hello, world"?

[dkinzer]

Will you publish the code for the modified "Hello, world"?

The preliminary version is attached. Later, we'll also put it on the Downloads page.

This version can't be compiled with the current release version of the compiler due to the use of a new built-in constant 'Option.ExtRamAble'. Also, for native mode targets the current compiler doesn't handle the ZXCmdMode() call correctly.

[dlh]

The version that was attached does not call ZXCmdMode().

[dkinzer]

Sorry, I attached the wrong .zip file.

[dlh]

Does ZxCmdMode() work with both VM and native devices?