ole00 / afterburner Goto Github PK

There are bugs in the Arduino sketch and in the PC software for this function. Both must be fixed together.
I made a fork on February 2nd, 2024 to test the fix.
https://github.com/hubertushirsch/afterburner // the unchanged fork of the master branch
https://github.com/hubertushirsch/afterburner/tree/hubertushirsch-afterburner-B9-fix

afterburner.ino
The offset range -20 to 25 (-co X) is transposed by the PC software into the range 0..9 and transmitted to the Arduino as command B0..B9. In the Arduino, however, the value 9 is not in the evaluated range, so the calibration around 0.25V can never take place.

You can see it when you send B9 to Afterburner on the serial terminal.

AFTerburner v.0.5.5
 varVpp
type 'h' for help
I: VPP calib. OK
>
B9
ER: cal offset failed
>

In addition, there is a typo in the explanation of the values 1:-1.5V ==> -0.15V

--- afterburner.ino     2024-01-28 22:29:17.000000000 +0100
+++ afterburner_fixed.ino       2024-01-29 21:12:33.365225100 +0100
@@ -2700,8 +2700,8 @@
       // small differences in analog ref which is ~3.3 V derived from LDO.
       case COMMAND_CALIBRATION_OFFSET: {
         int8_t offset = line[1] - '0';
-        if (offset >=0 && offset < 9) {
-          //0:-0.2V 1:-1.5V  2: -0.1V 3: -0.05V 4: 0V  5: 0.05V  6: 0.1V 7: 0.15V 8: 0.20V 9:0.25V
+        if (offset >=0 && offset <= 9) {
+          //0:-0.2V 1:-0.15V  2: -0.1V 3: -0.05V 4: 0V  5: 0.05V  6: 0.1V 7: 0.15V 8: 0.20V 9:0.25V
           calOffset = (offset - 4) * 5;
           Serial.print(F("Using cal offset: "));
           Serial.println(calOffset);

afterburner.c
If this bug is fixed, a bug in the PC program afterburner.c still needs to be fixed.
When the PC software is started, the global variable calOffset is initialized.

125: int calOffset = 0xFFFF; //calibration offset is not applied

What does 0xFFFF mean? This is compiler dependent. In an architecture where int is set to 16-bit, this would be -1, which is a valid calibration offset value in the range -20..25. Probably nobody has this architecture anymore today.
In a 32- and 64-bit PC architecture compiler, int is set to be at least 32 bits, so 0xFFFF is a large positive number (65535). This is (for now) outside the valid offset range -20..25.

But what does the parsing of the command line do in afterburner.c?
If there is a -co option on the command line, the value is read. If it is outside -20...25, a warning message appears.

afterburner.c lines 270..276
    } else if (strcmp("-co", param) == 0) {
         i++;
         calOffset = atoi(argv[i]);
         if (calOffset < -20 || calOffset > 25) {
             printf("Calibration offset out of range (-20..25 inclusive).\n");
         }
     }

Some lines later the values are corrected if they were outside the range.

afterburner.c lines 281..285
     if (calOffset < -20) {
         calOffset = -20;
     } else if (calOffset > 25) {
         calOffset = 25;
     }

However, this occurs outside the -co condition, so that calOffset then has a valid value in any case. If the -co option is missing, this corrects 0xFFFF (which is greater than 25) to 25.

What is the consequence:
With every b command from the PC software to the Arduino, a calibration offset is transmitted, regardless of whether a -co option is specified or not. Without -co option 0xFFFF => 25 => B9 is transmitted. A Verbose output confirms this.

$ ./afterburner.exe -d COM15 -v b <=== Executing without -co xx
Afterburner v.0.5.5
opening serial: \\.\COM15
variable VPP board detected
read: 5 ''
opening serial: \\.\COM15
variable VPP board detected
sending 'B9' command...     <= B9 is sending
read: 28 'ER: cal offset failed'   <== This failed in unfixed Arduino software
ER: cal offset failed
sending 'b' command...
VPP voltages are scanned - this might take a while...
....

Just because the unfixed Arduino program ignores the value at B9, the error in the PC program has no effect. If afterburner.ino is already fixed, the calibration offset is set to 0.25V instead. See my fixed branch for changes in arduino.c.

As last:
What should actually happen if the b command is called without -co?

• Should the last value stored in the Arduino's EEPROM be retained?
• Should b without -co implicitly set the offset to zero, i.e. work like b -co 0? Then in b without -co, B4 would always have to be sent to the Arduino. That would be my preferred option.

Let's say I'm repairing the Afterburner hardware (pot or something) and need to recalibrate according to the instructions.
Step 1: R9 in middle position
Step 2: ./afterburner s
Step 3: ./afterburner b What happens, there is an old offset in the Arduino EEPROM? I get incorrect values.
Step 4: ./afterburner m
./afterburner b -co X

The command 'i' (operationReadInfo()) does not send the type info to the Arduino. The Arduino sketch defaults to ATF16V8B. 22V10 GALs have a different number of pesbytes and therefore the readinfo returns the wrong data.

Don't know why but the chip just doesnt work as supposed, only simple equations works (for example when only one gate type is used for each output), 3.6V outputs instead of 5V, only the low signals are really 0V, also I have to config WinCupl in g16v8ma mode if not the chip almost does nothing, even if everything in the process of programing this ICs seems to be ok, reading the fuse map seems to be the same that is in the jed file only the last 6 lines of every single one is kinda diferent, example:

JEDEC file:
*L02048 01000000001100000011000000100000
*L02112 00000000111111111111111111111111
*L02144 11111111111111111111111111111111
*L02176 111111111111111111
*C14B5
*�9091

Read from the chip:
L2048 01000000*
N UES 0C 0C 04 00 00 00 00 00*
L2056 0011000000110000001000000000000000000000000000000000000000000000*
L2120 11111111111111111111111111111111111111111111111111111111111111111111111111*
N PES 31 42 38 56 36 31 46 31*
C14B5
*

I follow the instructions to program these, 10V, erase first, also tried the conditioning jed file from ATFblast for the ATF16V8B but in this case afterburner returns an error saying that the fuse map wasn't uploaded. Must say that in the moment I ran out of 4.7K resistor, so I used 10k and also tried 1K to see if there was any diference but it was the same, tried the x64 exe in windows 10, the linux executable in debian running under virtual box, even compiling with WinCupl in a windows 98 VM, all were the same results.

Also after some research I found that it was something kinda common for the Atmel PLDs, only GALs from lattice were working (with universal programmers as the TL866).

Did you have the same issue?

Sorry if my english is bad.
Thanks in advance

After i've programmed my GAL with program which i send below.I cant reprogram, erase, identify ic anymore.Just keep resetting arduino.I've programmed same ic before with simle and, or gates and it worked well without any problem.So i change the arduino, programming voltage but can not solve the problem.Is problem just ic or programmer?

Device g16v8;
PIN 2 = R;
PIN 3 = S;
PIN 19 = Q;
PIN 18 = QN;
Q = !(R # QN);
QN = !(S # Q);

Is there a forum connected to this project, to discuss troubles when building the device? My afterburner doesn't identify the GALs anymore. At the beginning afterburner did (but reported the GALs wrong).

Now I don't know where to locate the problem: arduino, afterburner, GAL-device or PC. I recognized the caps on the board are all parallel so they sum-up in value. Since the big cap has a tolerance of 20% (see bom.txt), the two small caps may not have an effect, since they are both very small. So I just tried a very large capacitor but without success. Also, measuring the total capacitance in-circuit, gave me a ten-times bigger value than the capacitors have alltogether. I think it's because the power-line is always surrounded by large ground-areas on the board.

All this is very interesting, but maybe completely unrelated to my problem. I tried additional power to the arduino, I tried all voltages from 10V to 14V for the GAL, and I tried three GAL-chips in total. I only have five of the same type and just wait for new chips to arrive. Next step is a logic-analyzer, to see if the chip is sending different signals than arduino/afterburner.

Erasing a chip is possible, but not reading and writing.

Hi,

I found a bug in the Arduino sketch for the Afterburner in the module aftb_mcp4131.h.

You have a function mcp4131_read(A), which is a wrapper for the function mcp4131_reg((A), 0, 1).
This function is used in mcp4131_detect() to detect whether an MCP4131 or an MCP4151 pot is present.
When mcp4131_detect() is executed, the variable mcp4151_detected is still 0 (zero) and mcp4131_read(A) reads back the native wiper value from the pot. That's ok here. If an MCP4151 pot was detected, mcp4151_detected is set to 1, for an MCP4131 the value remains at zero.

Subsequent calls to mcp4131_reg() via mcp4131_write() multiply the wiper value by 2 if mcp4151_detected == 1.
Likewise, calls via mcp4131_read() should divide the read wiper value by 2.

Here is the bug. The wiper value read is in the variable r.
However, the code divides the argument value of the function call (which is always 0 with mcp4131_read()) by 2.
The correct way would be to divide r by 2.

The code in aftb_mcp4131.h

94 if (mcp4151_detected && address == ADDR_WIPER && read_reg) {
95   value >>= 1; //divide the wiper value by 2
96 }

should be

94 if (mcp4151_detected && address == ADDR_WIPER && read_reg) {
95   r >>= 1; //divide the wiper value by 2
96 }

The bug only affects the varVppSetVppIndex() function, but only if an MCP4151 pot is installed and the debug option VPP_PARANOID is activated. The bug has no effect on normal operation.

Greetings
Hubert

In line 201 in the 'hints' section, Atmel ATF16V8C is misspelled AFT16V8C.

Christoph

a pal of me has made a simple GUI for your project. Do you want to have this tool in your repository ?

So i have few GAL20V8A and wanted to ask if they are supported or is it possible to add support for them

Do you think there would be enough space on the Uno to add in XSVF programming such that the ATF150x CPLD chips could be programmed via JTAG? They also work with WinCUPL...

I figure since afterburner is capable of generating the 12V required by the OE1 pin, this could fill the gap where standard JTAG programmers can't handle these devices without the additional programming voltage. Ever since the secrets of the OE1 pin have been revealed, the rest is standard JTAG to support several parts. I believe this would also work for the Altera MAX CPLDs, which are very similar, but I know less about these devices...

I propose a simplified form of voltage measurement in the Afterburner.
This affects the varVppMeasureVpp() function in aftb_vpp.h and some definitions.
The mathematical basics:

ADC = return value of analogRead()
Vin = voltage at the analog input
res = resolution - 2^10 = 1024 (10 bit resolution)
Vpp = programming voltage VPP
Vref = reference voltage of the A/D converter at pin AREF

Based on the basic formula

(1) ADC = Vin * res / Vref

After converting formula (1) we get

(2) Vin = ADC * Vref / res

Vin results from the voltage divider R5/R6

Vpp ---+
       |
       -
      | | R5
      | |
       -
       |
       o---- Vin to analog input
       |
       -
      | | R6
      | |
       -
       |
      ___ GND
      
(3) Vpp / (R5 + R6) = Vin / R6

Switched to Vpp

(4) Vpp = Vin * (R5 + R6) / R6

Vin substituted by (2):

(5) Vpp = (ADC * Vref * (R5 + R6)) / (R6 * res)

If you calculate with floating point, you can measure the Vref of your specific afterburner with a good multimeter and specify it precisely, e.g.

#define VREF (3.28)      // Vref in Volts as float

This also applies to the resistors R5 and R6, which can be measured beforehand.

#define ADC_R5 (99.96)   // R5 in kOhm as float
#define ADC_R6 (20.01)   // R6 in kOhm as float

I put the definitions of the parameters in a separate header file aftb_adcparms.h, which is included in aftb_vpp.h.
This makes it easy to adapt to your own hardware without having to spend a long time searching between the lines of code.
The varVppMeasureVpp() function has been completely rewritten.

Measuring using this method provides a significantly better agreement between the displayed VPP values compared to a multimeter.
The difference between the Arduino measurement and the multimeter was a maximum of 0.02V (Arduino NANO, Vref = internal 1.1V, R5 = 20k, R6 = 1.3k).

If I enable VPP_VERBOSE in aftb_vpp.h line 44

#define VPP_VERBOSE 1

then the output of the command in the PC program is cut off.

D:\<path> .\afterburner_w64.exe m -d COM15

VPP calib. offset: 0
VPP: 4.2 - 5.0V : varSetVppIndex 0
4.74
VPP: 9.0V : varSetVpp 0:44
varSetVppIndex 20
varSetVppIndex 44
9.01
VPP: 10.0V : varSetVpp 2:106
varSetVppIndex 51
varSetVppIndex 75
varSetVppIndex 87
varSetVppIndex 93
varSetVppIndex 96
varSetVppIndex 99
varSetVppIndex 102
varSetVppIndex 105
varSetVppIndex 106
10.01
VPP: 12.0V : varSetVpp 6:180
varSetVppIndex 88
varSetVppIndex 112
varSetVppIndex 124
varSetVppIndex 130
varSetVppIndex 133
varSetVppIndex 136
varSetVppIndex 139
varSetVppIndex 142
varSetVppIndex 145
varSetVppIndex 148
varSetVppIndex 151
varSetVppIndex 154
varSetVppIndex 157
varSetVppIndex 160
varSetVppIndex 163
varSetVppIndex 166
varSetVppIndex 169
varSetVppIndex 172
varSetVppIndex 175
varSetVppIndex 178
varSetVppIndex 180
12.01
VPP: 14.0V : varSetVpp 10:222
varSetVppIndex 109
varSetVppIndex 133
varSetVppIndex 145
varSetVppIndex 151
varSetVppIndex 154
varSetVppIndex 155
varSetVppIndex 156
varSetVppIndex 157
varSetVppIndex 158
varSetVp               <== cut off here
D:\<path>

Running the m command on the serial terminal, the output is complete.

MCP4151 POT found
AFTerburner v.0.5.8
 varVpp
type 'h' for help
I: VPP calib. OK
>
m
VPP calib. offset: 0
VPP: 4.2 - 5.0V : varSetVppIndex 0
4.75
VPP: 9.0V : varSetVpp 0:44
varSetVppIndex 20
varSetVppIndex 44
9.01
VPP: 10.0V : varSetVpp 2:106
varSetVppIndex 51
varSetVppIndex 75
varSetVppIndex 87
varSetVppIndex 93
varSetVppIndex 96
varSetVppIndex 99
varSetVppIndex 102
varSetVppIndex 105
varSetVppIndex 106
10.01
VPP: 12.0V : varSetVpp 6:180
varSetVppIndex 88
varSetVppIndex 112
varSetVppIndex 124
varSetVppIndex 130
varSetVppIndex 133
varSetVppIndex 136
varSetVppIndex 139
varSetVppIndex 142
varSetVppIndex 145
varSetVppIndex 148
varSetVppIndex 151
varSetVppIndex 154
varSetVppIndex 157
varSetVppIndex 160
varSetVppIndex 163
varSetVppIndex 166
varSetVppIndex 169
varSetVppIndex 172
varSetVppIndex 175
varSetVppIndex 178
varSetVppIndex 180
12.01
VPP: 14.0V : varSetVpp 10:222
varSetVppIndex 109
varSetVppIndex 133
varSetVppIndex 145
varSetVppIndex 151
varSetVppIndex 154
varSetVppIndex 155
varSetVppIndex 156
varSetVppIndex 157
varSetVppIndex 158
varSetVppIndex 159
varSetVppIndex 160
varSetVppIndex 161
varSetVppIndex 162
varSetVppIndex 163
varSetVppIndex 164
varSetVppIndex 165
varSetVppIndex 166
varSetVppIndex 167
varSetVppIndex 168
varSetVppIndex 169
varSetVppIndex 170
varSetVppIndex 171
varSetVppIndex 172
varSetVppIndex 173
varSetVppIndex 174
varSetVppIndex 175
varSetVppIndex 176
varSetVppIndex 177
varSetVppIndex 178
varSetVppIndex 179
varSetVppIndex 180
varSetVppIndex 181
varSetVppIndex 182
varSetVppIndex 183
varSetVppIndex 184
varSetVppIndex 185
varSetVppIndex 186
varSetVppIndex 187
varSetVppIndex 188
varSetVppIndex 189
varSetVppIndex 190
varSetVppIndex 191
varSetVppIndex 192
varSetVppIndex 193
varSetVppIndex 194
varSetVppIndex 195
varSetVppIndex 196
varSetVppIndex 197
varSetVppIndex 198
varSetVppIndex 199
varSetVppIndex 200
varSetVppIndex 201
varSetVppIndex 202
varSetVppIndex 203
varSetVppIndex 204
varSetVppIndex 205
varSetVppIndex 206
varSetVppIndex 207
varSetVppIndex 208
varSetVppIndex 209
varSetVppIndex 210
varSetVppIndex 211
varSetVppIndex 212
varSetVppIndex 213
varSetVppIndex 214
varSetVppIndex 215
varSetVppIndex 216
varSetVppIndex 217
varSetVppIndex 218
varSetVppIndex 219
varSetVppIndex 220
varSetVppIndex 221
varSetVppIndex 222
14.00
VPP: 16.0V : varSetVpp 14:250
varSetVppIndex 123
varSetVppIndex 147
varSetVppIndex 159
varSetVppIndex 165
varSetVppIndex 168
varSetVppIndex 169
varSetVppIndex 170
varSetVppIndex 171
varSetVppIndex 172
varSetVppIndex 173
varSetVppIndex 174
varSetVppIndex 175
varSetVppIndex 176
varSetVppIndex 177
varSetVppIndex 178
varSetVppIndex 179
varSetVppIndex 180
varSetVppIndex 181
varSetVppIndex 182
varSetVppIndex 183
varSetVppIndex 184
varSetVppIndex 185
varSetVppIndex 186
varSetVppIndex 187
varSetVppIndex 188
varSetVppIndex 189
varSetVppIndex 190
varSetVppIndex 191
varSetVppIndex 192
varSetVppIndex 193
varSetVppIndex 194
varSetVppIndex 195
varSetVppIndex 196
varSetVppIndex 197
varSetVppIndex 198
varSetVppIndex 199
varSetVppIndex 200
varSetVppIndex 201
varSetVppIndex 202
varSetVppIndex 203
varSetVppIndex 204
varSetVppIndex 205
varSetVppIndex 206
varSetVppIndex 207
varSetVppIndex 208
varSetVppIndex 209
varSetVppIndex 210
varSetVppIndex 211
varSetVppIndex 212
varSetVppIndex 213
varSetVppIndex 214
varSetVppIndex 215
varSetVppIndex 216
varSetVppIndex 217
varSetVppIndex 218
varSetVppIndex 219
varSetVppIndex 220
varSetVppIndex 221
varSetVppIndex 222
varSetVppIndex 223
varSetVppIndex 224
varSetVppIndex 225
varSetVppIndex 226
varSetVppIndex 227
varSetVppIndex 228
varSetVppIndex 229
varSetVppIndex 230
varSetVppIndex 231
varSetVppIndex 232
varSetVppIndex 233
varSetVppIndex 234
varSetVppIndex 235
varSetVppIndex 236
varSetVppIndex 237
varSetVppIndex 238
varSetVppIndex 239
varSetVppIndex 240
varSetVppIndex 241
varSetVppIndex 242
varSetVppIndex 243
varSetVppIndex 244
varSetVppIndex 245
varSetVppIndex 246
varSetVppIndex 247
varSetVppIndex 248
varSetVppIndex 249
varSetVppIndex 250
16.04
varSetVppIndex 0
>

Regards
Hubert

Hi, your proyect is excelente, but is missing the bom Material to replay it, because i dont know the value for resistors, capacitors. Can you tell me this? or can you up the schematic to check it?

Thank you very much

I have built v3.1a pcb using SMT components, a good MT3608 module but I am still having issues with afterburner calibration.

In order to get detailed info I have made the following modifications to the sketch files:

afterburner.ino (Line# 2703):
if (offset >=0 && offset <= 9) {

aftb_vpp.h (Line# 41)
#define VPP_VERBOSE 1

I have tested it with two different Arduino UNO R3 (chinese clones) and as I was not able to find the issue I have built the following circuit in a breadboard but the results were very similar.

There is only one change, in the v3.1a pcb I used a MCP4131-103 digital pot, in this breadboard version I used a DIP-8 MCP4151-103 digital pot.

v3.1a pcb (SMT) calibration output:

./afterburner s

Turn the Pot on the MT3608 module to set the VPP to 16.5V (+/- 0.05V)

varSetVppIndex 64
varSetVppIndex 112
varSetVppIndex 124
varSetVppIndex 126
varSetVppIndex 128
16.52
16.52
16.52
16.52
VPP OK
varSetVppIndex 0

./afterburner b

Using cal offset: 25
VPP voltages are scanned - this might take a while...

VPP calib. offset: 25
varSetVppIndex 1
varSetVppIndex 1

1. varSetVppIndex 2
2. *Index for VPP 900 is 1
   vppIndex 1
   varSetVppIndex 1
3. varSetVppIndex 2
4. *Index for VPP 950 is 1
   vppIndex 2
   varSetVppIndex 1
5. varSetVppIndex 2
6. *Index for VPP 1000 is 1
   vppIndex 3
   varSetVppIndex 1
7. varSetVppIndex 2
8. *Index for VPP 1050 is 1
   vppIndex 4
   varSetVppIndex 1
9. varSetVppIndex 2
10. *Index for VPP 1100 is 1
    vppIndex 5
    varSetVppIndex 1
11. varSetVppIndex 2
12. *Index for VPP 1150 is 1
    vppIndex 6
    varSetVppIndex 1
13. varSetVppIndex 2
14. *Index for VPP 1200 is 1
    vppIndex 7
    varSetVppIndex 1
15. varSetVppIndex 2
16. *Index for VPP 1250 is 1
    vppIndex 8
    varSetVppIndex 1
17. varSetVppIndex 2
18. *Index for VPP 1300 is 1
    vppIndex 9
    varSetVppIndex 1
19. varSetVppIndex 2
20. varSetVppIndex 3
21. varSetVppIndex 4
22. varSetVppIndex 5
23. *Index for VPP 1350 is 4
    vppIndex 10
    varSetVppIndex 4
24. varSetVppIndex 5
25. *Index for VPP 1400 is 4
    vppIndex 11
    varSetVppIndex 4
26. varSetVppIndex 5

./afterburner m

VPP calib. offset: 25
VPP: 4.2 - 5.0V : varSetVppIndex 0
11.25
VPP: 9.0V : varSetVpp 0:1
varSetVppIndex 1
12.95
VPP: 12.0V : varSetVpp 6:1
varSetVppIndex 1
12.94
VPP: 14.0V : varSetVpp 10:4
varSetVppIndex 0
varSetVppIndex 4
12.97
VPP: 16.0V : varSetVpp 14:121
varSetVppIndex 58
varSetVppIndex 82
varSetVppIndex 94
varSetVppIndex 100
varSetVppIndex 103
varSetVppIndex 104
varSetVppIndex 105
varSetVppIndex 106
varSetVppIndex 107
varSetVppIndex 108
varSetVppIndex 109
varSetVppIndex 110
varSetVppIndex 111
varSetVppIndex 112
varSetVppIndex 113
varSetVppIndex 114
varSetVppIndex 115
varSetVppIndex 116
varSetVppIndex 117
varSetVppIndex 118
varSetVppIndex 119
varSetVppIndex 120
varSetVppIndex 121
15.98

Breadboard calibration output:

./afterburner s

Turn the Pot on the MT3608 module to set the VPP to 16.5V (+/- 0.05V)

varSetVppIndex 64
varSetVppIndex 112
varSetVppIndex 124
varSetVppIndex 126
varSetVppIndex 128
16.48
16.50
16.52
16.49
VPP OK
varSetVppIndex 0

./afterburner b

Using cal offset: 25
VPP voltages are scanned - this might take a while...

VPP calib. offset: 25
varSetVppIndex 1
varSetVppIndex 1

1. varSetVppIndex 2
2. varSetVppIndex 3
3. *Index for VPP 900 is 2
   vppIndex 1
   varSetVppIndex 2
4. varSetVppIndex 3
5. *Index for VPP 950 is 2
   vppIndex 2
   varSetVppIndex 2
6. varSetVppIndex 3
7. *Index for VPP 1000 is 2
   vppIndex 3
   varSetVppIndex 2
8. varSetVppIndex 3
9. *Index for VPP 1050 is 2
   vppIndex 4
   varSetVppIndex 2
10. varSetVppIndex 3
11. *Index for VPP 1100 is 2
    vppIndex 5
    varSetVppIndex 2
12. varSetVppIndex 3
13. *Index for VPP 1150 is 2
    vppIndex 6
    varSetVppIndex 2
14. varSetVppIndex 3
15. varSetVppIndex 4
16. *Index for VPP 1200 is 3
    vppIndex 7
    varSetVppIndex 3
17. varSetVppIndex 4
18. varSetVppIndex 5
19. *Index for VPP 1250 is 4
    vppIndex 8
    varSetVppIndex 4
20. varSetVppIndex 5
21. *Index for VPP 1300 is 4
    vppIndex 9
    varSetVppIndex 4
22. varSetVppIndex 5
23. *Index for VPP 1350 is 4
    vppIndex 10
    varSetVppIndex 4
24. varSetVppIndex 5
25. varSetVppIndex 6
26. *Index for VPP 1400 is 5
    vppIndex 11

./afterburner m

VPP calib. offset: 25
VPP: 4.2 - 5.0V : varSetVppIndex 0
11.39
VPP: 9.0V : varSetVpp 0:2
varSetVppIndex 2
13.04
VPP: 12.0V : varSetVpp 6:3
varSetVppIndex 3
13.04
VPP: 14.0V : varSetVpp 10:5
varSetVppIndex 0
varSetVppIndex 5
13.06
VPP: 16.0V : varSetVpp 14:10
varSetVppIndex 3
varSetVppIndex 10
13.11

On the other hand,

1. README.md: There are several mentions to R8 but I think you want to mean R9.
2. bom.txt: "(R1 - 5x)" but in the pcb there are only 4 footprints for R1.

Thanks in advance

is it possible, to change the MCP4131 with the 4151 because of availability?
It's hard to find these part here in germany. But the MCP4151 is available.

Errors with:

Afterburner v.0.5.3 
opening serial: /dev/ttyACM0
Output from programmer not recognised: 
AFTerburner v.0.5.3
 varVpp 
type 'h' for help
>
result=-1

Possibly due to the function openSerial in afterburner.c: buf[total - 3] == '>' where there is variability on the newlines read at the end, so might need to check for '>' in the last few bytes as compared to only checking one position?

Howdy,
First of all, thanks for your great work.

I'm trying to build the afterburner, but sourcing those MCP413X pots is really a problem. The pot alternatives are not suited at all.

Was thinking in revamping the V3.0 board, using LM317 controlled by a PWM instead of the MT3608/MCP413X combo. It can withstand a 1.5Amp, and with a rebuild of the input to acomodate a much higher input voltage (say 30V), how much current would programming request? .. Do this 1A fit the bill ?

Another question is about the various voltages. In the code you use indexes to address wiper positions, considering a predefined adjustment, thats really neat. In this new proposed approach, a function handling this indexes would convert to the needed PWM , that way it would give out the correct ratio to LM317.
And the final question. Found voltages ranging from 5V ~ 19V ., .. would there be more? .. .and what would be the minimum step requirement (in volts/step ) ... and the slew rate of the ramp-up ?

Best Regards..

In afterburner.ino line 2252 the type is decoded as char type = line[1] - '0';, but in the pc program it is sent as sprintf(buf, "#t %i\r", (int) gal);. Above 10, the value will be two chars, which makes the decode wrong.

This can be solved with one of these two solutions:

1. Make the arduino side parse an integer
2. Send sprintf(buf, "#t %c\r", gal + '0'); instead

I'm trying to understand your code better. I noticed sequences that were not clear to me.

afterburner.ino

0120: #define READPES 2

1033: // GAL init sequence
      static void turnOn(char mode) {
          setupGpios(OUTPUT);

          if (mode == READPES) {
              mode = 2;               // mode = 2 = READPES -> there is no change
1039:     } else
..........
1065:     setVPP(mode);
          delay(20);
1068: }

You test mode for the value READPES, which is defined with the value 2. if mode == 2 then mode = 2 ???

afterburner.ino
There is a global variable vpp, which is set to a type-specific value depending on the GAL type.
In setVpp() you calculate a value v (line 852), which is used in varVppSet(v) (line 860) as an index in vppWiper[v] .
vppWiper[] contains the wiper values for the calibrated voltages from the EEPROM.

In lines 849/850 you set vpp = 40 for a limitation to 12V. But your formula leads to 10V (v = 2 (index VPP_10V0)).
See my included comments. 12V would be the result at vpp = 48 ==> v = 6 (index VPP_12V0).
Which is correct here, 10V or 12V?

0379: static uint8_t vpp = 0;

0832: static void setVPP(char on) {
          // new board desgin
          if (varVppExists) {
0835:         // uint8_t v = VPP_11V0;
              uint8_t v;     // v is recalculated in each case; initialization of the variable is unnecessary
..........
0844:         } else {
                  //safety check
                  if (vpp < 36) {      // set vpp < minimum to 9V0
                      vpp = 36; //9V   // ==> v = (36 / 2) - 18 = 0 ==> VPP_9V0
                  } else
0849:             if (vpp > 66) {      // set vpp > maximum to 10V0
0850:                 vpp = 40; //12V  // ==> v = (40 / 2) - 18 = 2 ==> VPP_10V0 !!!!!!
0851:             }
                  // 36 <= vpp <= 66      ==> v = 0 ... 15 ==> VPP_9V0 ... VPP_16V5
0852:             v = (vpp >> 1) - 18; // 18: 2 * 9V, resolution 0.5V (not 0.25V) hence 'vpp >> 1'
      #if 0                  
                  ......
      #endif                  
              }
0860:         varVppSet(on ? v : VPP_5V0);
              delay(50); //settle the voltage
0862:     }

So I've tried 57600, and it's pretty hard to get it to work reliably.

I would prefer 115200, only my MCP2200 serial chips work at 57600.
I think it would be easier to use 115200, all UNO boards have to be accurate enough to upload at that speed.

Any reasons for not going with 115200(So I'm not left in the dark)?

I just put together an Afterburner, and I had a heck of time trying to get it calibrated.

I eventually figured out that the MT3608 module that I was using had the wiper and low-side terminals of the pot shorted together.
At first, I tried to work around this by lowering R2's value, but I wasn't able to achieve the 5V-16.5V range.
I eventually chose to desolder the module, desolder the pot, cut the shorting trace, and put it all back together again.
Eventually, I could get it calibrated.

Btw, if you change line 196 of aftb_vpp.h to have less-than-or-equal instead of just less-than, it will avoid an odd corner case for when the voltage reading fails to increase initially and it sets all the indexes to 1. Of course, you normally shouldn't run into this unless you've got an odd MT3608 module.

Finally, I also faced the issue of my Arduino's A/D measurement of VPP being off (low) by 0.8V (for 16.5V). I had to increase the value of R7 by 2.4K to get the readings to within 0.1V. I'm not quite sure why that was the case.

Anyway, I got my chip programmed, and I'd like to thank you for putting this project together.

Thank you for your great work! It made me want to start playing with GALs.
I have a few questions about your programmer:

• What should be the voltage for an ATF22V10 (10V, same as for ATF16V8)?
• I ordered ATF22V10C (not ATF22V10B). Will afterburner still work with those GALs?
• What is the 7 segment display used for on your design?

Thanks

In line 188 in the printHelp() function the serial baud rate used is incorrectly specified.
The help text says 38400 but the code uses 57600.

In addition in printHelp(), the default device (if no -d 'device' option is specified) is not always COM1 (on Windows), but the highest COM number found (since the extension in serial_port.h).

Hubert

Only the D version is readily available where i am. Has it been tested? The docs only list the B version (GAL22V10B).
Haven't had a chance to test it myself yet, as i'm missing some IC and waiting for it to arrive, but seeing all the compatibility with something not supported issues, thought it would be nice to ask first.

Looks like Microchip has re-dis-organized their web site, and the link to WinCUPL is no longer valid. I think that this one might be correct:
https://www.microchip.com/design-centers/fpgas-and-plds/splds-cplds/pld-design-resources

Also, please note that apparently Microchip has taken over Atmel, and in many places what used to be listed as Atmel chips are now listed as Microchip.

This is a part from Texas Instruments. I have not found any concrete reference to it in the readme or in discussions here so I'm curious if anybody tested that and if it works. Thanks!

I have observed that when removing a GAL (currently only have ATF16V8B) the LED sometimes flashes.
This depends on how I move the chip when removing it and in which order the pins lose contact on the ZIF socket.
Since the Powerswitch SW1 is switched off, the current through the LED must come from another connection on the ZIF socket that has a HIGH level and flow through the inactive GAL chip.
In fact, ZIF16 (Arduino D9, DOUT for this GAL type) is set to HIGH due to the pin mode on D9
pinMode(PIN_ZIF16, INPUT_PULLUP); //DOUT
after the first command.
A test shows: When connecting a wire from ZIF16 to ZIF15, the LED lights up.

I don't know whether this could destroy the GAL when plugging or removing it in the worst case scenario.
Is it possible to change the sketch so that there is no HIGH level at the DOUT of the last selected GAL type if the GAL is not addressed by a command?
The best would be a pulldown resistor, but this cannot be programmed on the Arduino input.
The alternative would be INPUT without pullup, but that would be a floating input.

The conosle prints "GAL20V10" when there is a GAL22V10 inserted
I´m guessing it´s a typo becouse of this line in the arduino code: "case GAL22V10: Serial.print(F("GAL20V10 ")); break;"

Also I designed an Arduino nano alternative for the afterburner, I dont know if anyone would be intrested becouse it uses a 24 pin ZIF & I´ve only tested it with the GAL22V10D15LP

I am using Win10 x64 with Arduino IDE v1.18.13 , and Ubuntu Budgie With Arduino IDE va.1.18.13

On both sides i am facing this error about "termios.h"

In file included from sketch/afterburner.c:52:0:
serial_port.h:114:10: fatal error: termios.h: No such file or directory
 #include <termios.h>
          ^~~~~~~~~~~
compilation terminated.
exit status 1
termios.h: No such file or directory

Any help regarding this will be appreciated.

Hi ole00,

I am testing an unknown GAL problem, this is my read information, After inserting the afterburner into the USB, read ATF22V10C directly and continuously, All are the same chip.
Maybe the i command reset the Type parameter?
ps. The chip can read/write correctly on "-t ATF22V10C"

c:\>afterburner_w64 -d COM4 i -t ATF22V10C
testing gal 4
PES raw bytes:
FF FF 0F 00 00 00 00 00 00 00 
PES info: 3.3V Unknown GAL,  try VPP=10..14 in 1V steps

c:\>afterburner_w64 -d COM4 r -t ATF22V10C
testing gal 6
PES raw bytes:
33 43 30 31 56 32 32 46 31 FF 
JEDEC file for ATF22V10C
*QP24*QF5892*QV0*F0*G0*X0*
L0000 11111111111111111111111111111111111111111111*
L0044 11111111111111111111111111111111111111111111*
L0088 11111111111111111111111111111111111111111111*
...
...
L5764 11111111111111111111111111111111111111111111*
L5808 11111111111111111111*
N UES FF FF FF FF FF FF FF FF*
L5828 1111111111111111111111111111111111111111111111111111111111111111*
N PES 33 43 30 31 56 32 32 46 31 FF*
CDD2F
*

c:\>afterburner_w64 -d COM4 i -t ATF22V10C
testing gal 4
PES raw bytes:
FF FF 0F 00 00 00 00 00 00 00 
PES info: 3.3V Unknown GAL,  try VPP=10..14 in 1V steps

Hi there,
many chinese online-sellers offer the chip "Lattice GAL20V8B" for a few bucks. Is this chip supported by the programmer? The chip is a lot cheaper than the bigger brother GAL22v10B but costs a bit more than GAL16V8A, GAL16V8B and GAL16V8D, which are officially supported by the programmer.

I built the programmer and managed to program the ATF22LV10C by selecting ATF22V10C and using -v to override detection.
12V programming voltage needed, 10V did not verify correctly.

Hi, you project support this chip ?

I'm interested in building this, but don't have much experience with Arduino.

There is another project that uses a Mega to read/write EEProms. It needs the extra digital I/O.

Would this just run on the Mega since they seem to have the I/O port in similar places? Also have you thought about selling this on Tindie or somewhere else?

HI,
I'm using a different hardware and a different power supply solution to switch Vpp for the GAL (instead of the 5V/12V MT3608 module). Also my Hardware is a Arduino Nano instead o the Arduino UNO. This combo works fine for the Lattice 16V8 (right from the beginning) but the ATF22V10C is not getting recognized.
After hours of drudgening error seeking with the voltmeter and the oscilloscope I wonder if there is a bug in the sw. You sure you have tested your hw with a F22V10CQZ?

Regards,
Joachim

Hi guys,

so I just built the Afterburner ( let' see if I can add a pic here ) , this is my version using Arduino Pro Micro and SW I lightly modified to make it work with Platform Io

As you can see I went for the route of "an external power supply", no rocket science, plain simple 78S05 with some caps.

I had a bit of a nightmare story with the MT3608 module, I found out for me the simplest way was to lift up pin 4 and solder a small wire , but I also found the set ( 5 ) I bough on Amazon was defective, it was missing a connection between a resistor and the feedback loop making the regulation non-existent ( luckily it was stuck at 4.84V ), you can see a second wire in my pic ( that's the missing connection ).

Anyway so far been trying with 2 chips with the VPP set at precisely 10.0V , an ATF22V10C and an ATF16V8CZ

With the 16V8C I get the following thing ..

afterburner -v -t ATF16V8B i -d COM11

Afterburner v.0.3
opening serial: \.\COM11
read: 5 ''
opening serial: \.\COM11
read: 5 ''
opening serial: \.\COM11
sending 'p' command...
read: 62 'PES info: 3.3V Unknown GAL, try VPP=10..14 in 1V steps'
PES info: 3.3V Unknown GAL, try VPP=10..14 in 1V steps
result=0

( what is that read '62' is the ID code ?? )

If I try with the 22V10 instead things seems to go OK ( I yet have to try the chip itself ) however just to let you know this is what I see ..

afterburner -t ATF22V10C i -d COM11
PES info: Atmel ATF22V10C VPP=10.0 Timing: prog=10 erase=25

JEDEC file for ATF22V10C
QP24QF5892QV0F0G0X0*
L2156 11111111111111111111111111111111111111111111*
L2200 11110111111111111101111111111111111111111111*
L2904 11111111111111111111111111111111111111111111*
L2948 11110111111111111110111011111111111111111111*
L2992 11110111111111111101110111111111111111111111*
L3652 11111111111111111111111111111111111111111111*
L3696 11110111111111111101110111011111111111111111*
L3740 11110111111111111111111011101111111111111111*
L3784 11110111111111111110111111101111111111111111*
L4312 11111111111111111111111111111111111111111111*
L4356 11110111111111111101110111011101111111111111*
L4400 11110111111111111110111111111110111111111111*
L4444 11110111111111111111111111101110111111111111*
L4488 11110111111111111111111011111110111111111111*
L4884 11111111111111111111111111111111111111111111*
L4928 11111111101111111111111111111111111111111111*
L4972 11111111111111111111111111111101111111111111*
L5016 11111111111111111111111111101111111111111111*
L5808 00000000000000001100*
N UES 30 30 20 00 00 00 00 00*
L5828 0011000000110000001000000000000000000000000000000000000000000000*
N PES 33 43 30 31 56 32 32 46 31 FF*
C5EC5
*

And this is the original .JED file I used as output by WinCPUL .. as you can see despite "verify" and all is O.K. the file looks a bit different ( look at those lines of '000000' ) is that normal ?

CUPL(WM) 5.0a Serial# 60008009
Device g22v10 Library DLIB-h-40-1
Created Sun Sep 26 15:57:05 2021
Name VT100
Partno 00
Revision 01
Date 31/07/2021
Designer Engineer
Company XXXXXXXXXXXXXXX
Assembly None
Location Wales
*QP24
*QF5892
*G0
*F0
*L02144 00000000000011111111111111111111
*L02176 11111111111111111111111111110111
*L02208 11111111110111111111111111111111
*L02240 11110000000000000000000000000000
*L02880 00000000000000000000000011111111
*L02912 11111111111111111111111111111111
*L02944 11111111011111111111111011101111
*L02976 11111111111111111111011111111111
*L03008 11011101111111111111111111110000
*L03648 00001111111111111111111111111111
*L03680 11111111111111111111011111111111
*L03712 11011101110111111111111111111111
*L03744 01111111111111111110111011111111
*L03776 11111111111101111111111111101111
*L03808 11101111111111111111000000000000
*L04288 00000000000000000000000011111111
*L04320 11111111111111111111111111111111
*L04352 11111111011111111111110111011101
*L04384 11011111111111111111011111111111
*L04416 11101111111111101111111111111111
*L04448 01111111111111111111111011101111
*L04480 11111111111101111111111111111110
*L04512 11111110111111111111000000000000
*L04864 00000000000000000000111111111111
*L04896 11111111111111111111111111111111
*L04928 11111111101111111111111111111111
*L04960 11111111111111111111111111111111
*L04992 11111111110111111111111111111111
*L05024 11111111111111111110111111111111
*L05056 11110000000000000000000000000000
*L05824 11000011000000110000001000000000
*C5EC5
*�46E7

Thanks a lot for any help, btw I know very little about how to use GitHub ( I am used to SVN ).

Any help appreciated, cheers.

Built a PCB to the schematic but couldn't get the programming voltage to work.
Thought it may be the MT3608 module (modified as instructed) having some issues as other users on the web have claimed. Modified the module to only output 9 to 16V when enabled which worked very occasionally.
Thought some more and realised that the Arduino was often resetting when the 5V supply was switched on and the USB link to PC was interrupted (Beep off/Beep on sounds)
(Arduino is an old type with plug-in mega328)
I think firstly that the USB feed cannot cope with the MT3608 switch-on surge so I added an external 9V PSU. This only helped a little.
I suspect also that the Arduinos's 5V regulator cannot handle the switch-on surge current to the MT3608 module.
I have now added a 7805 regulator from Vin arduino pin to feed the 5V input to this board. (Arduino 5V connection removed) so now the MT3608 supply and the Vcc to the PLDs is independent (except for a diode on the aduino) of the aduino pwer supply using the 9V PSU. The arduino may also use this PSU but can use the USB if necessary. It does mean that the external 9V PSU must be present to use the system. Seems to work OK!
Next version of my PCB will incorporate a 78l05* to power the PLDs Vcc and a 7805 with Schottkey diode to give 5.3V to the MT3608 (Should give 5V out when not enabled - compensates for the series diode drop.)

• May need to be a bit beefier, these PLDs can take nearly 100mA when active.
  I can now try to program a PLD.