T962 Reflow Oven?

[jpanhalt]

Mine arrived on Saturday and I dug into it today.  Its MCU is an LPC2134.  Some of the procedures are for the LPC2148 (newer).  At first glance, the boards may be slightly different.  I need to find out whether the difference in the image of the LPC2148 board is a modification done by the user or from the factory.

Also need to be sure the hex file for the LPC2148 is compatible with the LPC2134 or visa versa. 

BTW, the FlashMagic problem was a Google Chrome security setting  (as suspected).  That was easy to work around.

[jpanhalt]

My questions are really noob.  I always write my own code (with help) and have never downloaded a library much less a hex file.  I also write in Assembly, use an Assembler, and have never used a C compiler.

1)  The hex file linked in post #10 here (https://www.eevblog.com/forum/reviews/t-962-reflow-oven-anyone-done-the-github-firmware-mod/ ), and on other sites all decompress to more than 125 kB.  At least that is what the file size on my Win7 PC says.  The LPC2134 chip used has 125 kB of flash memory.   Is that an issue?  Are the byte sizes the same?

2)   Does that hex file (0.5.2) support the Dallas DS18B20 1-wire sensor, or does one have to add an additional file?

[donotdespisethesnake]

Hex files are ASCII, so the size won't match the binary size.

0.5.2 supports DS18B20.

[jpanhalt]

Thanks, I suspected something like that -- particularly after I checked the default hex file that is also on GitHub.  It was confirmed this morning when I finally had the guts to load 0.5.2 file into FlashMagic. 

My problem now is getting into bootload.  I keep getting the dreaded message about autobaud not configured.  Also, no crystal frequency is shown in the starting page.  I am thinking about re-installing FlashMagic.

[jpanhalt]

Have spent more than a day trying to get FlashMagic v.2.12.28.0 (current) to recognize the chip. 

Chip (LPC 2134/01) seems to enter bootload mode (screen blank, both LED's lit) using the standard procedure of holding n_RESET low, touching n_ISP low, then floating both, but all attempts to communicate (changing bauds, swap TX and RX, change settings, follow trouble shooting "tutorials" on the internet -- about 14 hours of frustration) fail and all I get is the dreaded and very common,"Operation Failed. Failed to autobaud - Step 1" error. 

My FTDI connector (232R-3V3) is about 6 or 7 years old, so  I loaded X-CTU (Digi corp) and tested echo.  That worked.

Connection is to "com 6." I have tried every baud available from 9600 to 115200.

Any ideas?  Could an older version of FlashMagic offer any hope?  If so, what version have you had success with?  My PC is running Win7 32/64.

[SMdude]

I remember when I did my oven I had the same problem and it did my head in, however I can't for the life of me remember what I did to solve it!
I kind of think it might have been a logic voltage level problem. Uart, 5v, 3.3v?

[TomS_]

One common problem I see that continually pops up with these ovens is connectors that burn or melt.

It may not necessarily be a problem with the machine, and maybe just needs some experimentation with different manufacturers or flavours of connectors to find the ones that play well. Or Ive also seen suggestions that the connectors need to be capped or covered to prevent direct IR exposure.

Ive been looking at one for a long time as well, so interested to hear what other people experience in this respect.

[KE5FX]

Any ideas?  Could an older version of FlashMagic offer any hope?  If so, what version have you had success with?  My PC is running Win7 32/64.

Flash Magic is kind of a dumpster fire IMO.  I have a command-line programmer based on an open-source release by Martin Maurer that works well with at least some devices in the family (specifically, I've used it with the LPC1837 and LPC18S37.)  Curious to hear if it works on the LPC2134, if you want to give it a try.  The usual caveats apply -- it may brick your MPU, burn down your house, or cause cancer in California.

Ive been looking at one for a long time as well, so interested to hear what other people experience in this respect.

Yeah, absolutely, it takes a while to dial it in.  Be sure to order several spares of any plastic connectors you plan to use.  An IR oven this small can be very handy but it will never work perfectly in all cases.  Nature of the beast.

[jpanhalt]

Thanks,

I am in Ohio, so any cancer it causes in California won't affect me.

On the second matter of melting stuff, since this is my first shot at reflow, I chose components that I could also hand solder.  One troublesome part was a 12-pin 0.5 mm ZIF for FFC/FPC.  I tried a few connectors that looked about right and settled on the Molex type 1084 (Digikey  WM11084-CT-ND, Molex #0528921233).  The pins were about the same on all 4 of the choices I tested, but that device had exposed mounting lugs.  Tried it and with care, it can be hand soldered without damage to the plastic.
.

[jpanhalt]

Here's another follow-up.

After many more hours, I hooked up an oscilloscope to the FTDI and ISP pinheaders.  Signals are getting to Pin 4 of the ISP, which is RXD.  Response  (Pin 3) is completely dead.  Even though the screen is blank or messed up, both leds on the front are on, and the red LED on the board is off, nothing. 

I have tried getting into bootloader mode starting with power up (i.e., Pin 1 is grounded at power up and after the MCU boots into normal operating mode.  Same result.

Cables to the heaters and TC's are disconnected to give more working room, but I don't see how that should affect getting into bootloader mode.

[jpanhalt]

I am beginning to think the TX function of the LPC2134 on my board is dead.   It boots fine, but takes awhile.  All attempts to get it to acknowledge a ? have failed.

The TX pin (#19, P0.0) stays low.  Resistance to ground is about 140 Ω.  Tried pulling it high with a 4.7 k resistor to no avail.

Does anyone know what the resistance from that pin to ground should be?  On my FTDI cable the corresponding pins are pulled high.

[Weston]

The TX pin is an output so I would expect it to read low resistance. Serial idle state is V+ though. Can you check the voltage on the pin? It should be ~3V3.

I would assume that the chip goes through a full reset on power up, but you should try cycling the reset pin too as detailed here: https://github.com/UnifiedEngineering/T-962-improvements/wiki/Flashing-the-LPC21xx-controller

I used the flash utility for linux, not flash magic, but I just upgraded the firmware on my oven last week following the instructions on the git repo and it went fine. 


As a side note, has anyone noticed a temperature gradient across their T962? The whole oven looks rather symmetrical from left/right, but the right side of my oven is consistently ~ 25C hotter than the left, as measured with an external thermocouple. It's not that big a difference, I should be able to reflow PCBs on the left without nuking PCBs on the right, but it's still a bit concerning.

[jpanhalt]

The TX pin is an output so I would expect it to read low resistance. Serial idle state is V+ though. Can you check the voltage on the pin? It should be ~3V3.

The pin stays low (~0.0 V) when measured with an oscilloscope and DMM.   

It was only after days of trying everything on GitHub and elsewhere that I tested resistance to ground.  Pulled the header off the board to look for shorts that might be hidden.  None.  Even touching a lead from the 4.7 k resistor added for the cold junction modification did nothing.

[Weston]

It seems possible you could have blown the chip then, but I don't see how you could have easily. Even if you connected tx to tx it would have likely survived. Is your computer a desktop and you plugged in the serial cable RX pin in first or something? I have killed boards with setups like that before due to floating potentials being discharged though grounded equipment. 

However, even before checking the TX pin, it seemed you were having issues with the flash utility. It might be worth trying to set up something running linux to run the makefile based flash procedure provided in that repo. I had no issues in Ubuntu 18.04 using ~ the cheapest USB <> serial cable sold on amazon ( https://www.amazon.com/JBtek-WINDOWS-Supported-Raspberry-Programming/dp/B00QT7LQ88/ ).

Worst case, if you have fried the microcontroller you should be able to get a replacement off digikey.

[jpanhalt]

It is a desk top computer.  The cable is FTDI TTL-232R-3V3.  I have used both a terminal emulator (Digi) that I have used to setup XBee and Flash Magic.

At first, I just set TX --> RX and RX --> TX as usual.  After getting no results, and since some of the many "tutorials" said it should be TX --> TX, which didn't make sense, I tried that anyway.  No luck.   Then I started trouble shooting, set up a scope, etc., and everything has been TX --> RX as usual.  The FTDI cable with either program works exactly as expected.  With the terminal emulator, it echos just fine too. 

When I noticed TX from the LPC2134 was always low, I removed the board, and visually inspected for soldering shorts. Saw some shadows I didn't like.  Upon cleaning, those turned out to be old flux, not solder.  Re-install.  Same problem.  At some point, I used  my DMM to check continuity.  Continuity was OK, but resistance to ground was low on the TX pin.  A weak pull-up didn't work. 

My working hypothesis is that something like latch-up has affected that pin.  A new chip was ordered from DigiKey yesterday and is expected Saturday.

Reviewed the NXP User Manual and will try some things to the RX in hopes of unlocking the TX.  The datasheet does mention the possibility of I/O pin latch-up at 100 mA.  I certainly didn't apply anywhere near that current intentionally when using a 4.7 k pull-up.  The maximum output current for the FTDI cable is listed as 75 mA, so if I fried it, it was my fault when I swapped the lines.

BTW, I did notice one small difference from the schematic on GitHub.   That shows the ISP pin (P0.14) pulled up to +5.0 V; my board has the pull-up resistor to the 3V3 rail. 

As for using Linux, I am just not savvy enough to start that journey now.  Will just stick with the Digi emulator to send commands. If I can get the chip's TX to respond, I will be happy.  Otherwise, I have a few hours work to do on Saturday. 

[Dubbie]

Sorry to hear that you have had such a bad experience.

I hope that replacing the uC will sort things out for you.
Flashing the new firmware was extremely painless for me, so I am thinking there must be something deeper wrong with your hardware. You seem to have exhausted all of the basic troubleshooting steps.

[jpanhalt]

UPDATE

The LPC2134 chip arrived a day early and is installed.  It's alive.  On the removed chip, TX (P0.0, pin19) read the same 145 Ω to ground as it did in circuit.  The new chip shows the TX at the expected 3.3V.  In terminal, it echos a '?' , but Flash Magic is giving an error when I ask to start bootloader: "Start Root ROM command _ no '.' received." 

If I do "Start" instead without a hex file loaded, the error is as expected, "No hex file loaded."

At least there is light. 

Presumably, boot loader is started with POR when ISP is grounded, and then released.  Is there a need to go through the "start bootloader" in Flash Magic?

[jpanhalt]

UPDATE#2

Kept having problems with communications when I started with "start bootloader."  So, I figured a new chip must be empty and the chip most likely enters bootloader on POR since there is no valid user program (see flow charts in datasheet).

I booted with ISP grounded (P0.14) (probably not needed).  Reset pin was left open. Set baud to 57,600 and hit program.  I had my scope on the TX and RX lines as I wanted to see the handshaking and really didn't expect it to work.  If I were to do that again, I would disconnect the scope to reduce chance of noise.

Programming took off.  Every unit was programmed, except verify sent an error: "difference in value stored at 0x0000 0000"  It did not say what the expected and found values were.  The progress showed every page (?) programmed, including 0x0000 0000 - 0000 03FF.

Shut everything down, turned it on, and the Unified Engineering splash screen came up. After connecting the TC's, oven temp showed 26°, which was about right within a couple of degrees.

Tomorrow, I will attach the Dallas temp sensor and give the thing a try.

[jpanhalt]

UPDATE #3 Questions

Got it all back together.   The 1-wire sensor I have is made by Maxim, so presumably works in parasitic mode, which is how I set it up.

1) How can one monitor the cold junction temperature during a run?  Switching to manual mode shows a cold junction temperature, but I have reason to doubt its accuracy.  Did you do the 1-wire version or run a 3v3 line to the Dallas/Maxim sensor?

2) There are instructions for the modifications everywhere.  Is there a consolidated user's manual for the modified oven?

[Dubbie]

I did the one wire temp sensor. I do remember that the first sensor I bought, I could not get to work. I mistakenly bought a Maxim DS18S20+-ND the first time. I then bought a DS18B20+-ND and that part worked fine.

[jpanhalt]

My sensor seems to work in parasitic mode.  It's the Maxim version.  Occasionally, it gives a bizarre cold-junction temp, such as 85°C.  Turning the oven off and on again fixes that.  A bit unsettling, but the firmware is free.

I have a Fluke TC and calibrated mercury thermometers.  The Fluke agrees within 0.5°C of the mercury thermometers up to 200°C (highest temp tested).  The oven thermocouples are all over the place individually, but surprisingly, by tweaking the offset and gains, the "actual temperature" matches that thermocouple within a few degrees when it is placed in the oven center and at the same height as the PCB's will be.

Will run some reflow tests tomorrow with Kester EP256, which is fresh and within expiration date.

[Weston]

Congrats on getting it working!

I also had the cold junction temp jump to 85C a few times in bake mode. I believe that 85C is the temperature it initializes at so something is funky with the sensor or the library to talk to it. This thread shows there are lot of fake ds18b20: https://www.eevblog.com/forum/projects/fake-ds18b20/ . I got my sensors from a friend who ordered them off amazon, so I assume they are fake and that is what causing the issue, I will have to add some real ones to my next digikey order. On the plus side, it seems they will read either 85C or something close to the real temp, so its not going to cause your boards to bake or the oven to catch fire.

I was able to get the individual thermocouples to match an external meter pretty well, but there is still a ~15C difference between the left and right side of the oven. I assume its an issue with non-uniform insulation or heater bulbs.

[jpanhalt]

Congrats on getting it working!

I also had the cold junction temp jump to 85C a few times in bake mode. I believe that 85C is the temperature it initializes at so something is funky with the sensor or the library to talk to it. This thread shows there are lot of fake ds18b20: https://www.eevblog.com/forum/projects/fake-ds18b20/ . I got my sensors from a friend who ordered them off amazon, so I assume they are fake and that is what causing the issue, I will have to add some real ones to my next digikey order. On the plus side, it seems they will read either 85C or something close to the real temp, so its not going to cause your boards to bake or the oven to catch fire.

My DS18B20 is direct from DigiKey.  Maxim is the manufacturer.

I was able to get the individual thermocouples to match an external meter pretty well, but there is still a ~15C difference between the left and right side of the oven. I assume its an issue with non-uniform insulation or heater bulbs.

10° to 15°C is about what I am seeing.  The TC's are quite fine wire that is twisted together for a short distance (3/16" or so) and with what looks like a small weld at the tip. I did something similar with slightly heavier wire and used my CD welder to weld the tip.  It raised havoc with the MAX31856 TC digital amplifier I am using in a real project ( got the T-962 to reflow that board). It made the RDY interrupt interrupt unreliable, particularly if you moved it slightly.  We used to make them in school using a hydrogen/oxy torch.  I don't have that anymore, but I used my TIG welder to make these:


Those were just for practice.  I avoid the twist and have only one junction.  They work much better with the MAX31856, and I have had no problems with the interrupt since.  I am considering removing the TC's from the oven and re-welding them.  Being bigger, the ones shown have a little more lag, so I will probably use the original TC wires that came with the oven.

[jpanhalt]

TEST RUN OK

I got the internal TC's to agree reasonably well compared to my Fluke TC, which agrees well with a mercury thermometer.  Set L gain = 1.0, offset = -5.0 and R gain = 0.82, offset =.25.  One cause for big differences between the two TC's seemed to be slow fan speed, so I set the min to 20 and may consider going higher.

Did a trial board with Kester EP256, which has a recommended peak temp of 208° to 230°C.  The actual lagged bethinfd the set, but did reach that range and reflow looked decent (just used dabs of paste and no stencil for this test).

Unfortunately, I didn't plan ahead to photograph the curve, so I had to hand hold the camera.  Sorry for the blur:


John

[Dubbie]

Nice one. I look forward to seeing a full populated board flowed!