FWIW, I've just successfully flashed a good working version using LPCXpresso 8.0.0 after battling for hours to get a stable build that didn't crash with a WDT when pressing F2 (setup). The only real change I made was to redownload the master branch .zip from here : https://github.com/UnifiedEngineering/T-962-improvements and import it into LCPXpresso.

Before I was using the 0.5.1 code from here : https://github.com/UnifiedEngineering/T-962-improvements/releases which seems to have issues with the current toolchains.

Might have been lucky co-incidence, but worked for me. Hope you come right.

from t-962-improvements.

I've not been as careful as I should with keeping track of where I am, but I'm as certain as I can be that I have found almost the same thing. I know for sure the downloaded hex from the master works fine. I'll be more methodic, and compile the master source and test it, then try the later builds.

You say "import it", do you mean that literally. I thought you could just open the project if you left .project, .cproject and /src in the outer directory but it didn't seem that way. I had to end up using Import then "Existing Projects into Workspace" and let it copy everything over. Then change options to GNU99 and Build it. Is that more or less what you did?.

I wish I knew something about debugging this setup. I feel that we have a link for flashing the chip, but I'm lost without some form of debugging.

from t-962-improvements.

I too wasn't making careful notes, but I'm pretty sure I did a 'Download ZIP' from the master, then did an 'import project' from the quickstart menu (bottom left of the IDE) like this :

Seems to work OK

from t-962-improvements.

OK, I have gone back to the last public released source code, 'master' from 25 Feb 2015. It build fine, but comparing the two hex files shows over 90% different. They are not even the same length. I am surprised by this as they both (I think) use the eabi toolchain. Only difference I've made to this source project was to change the language type to GNU99 or would not build under LPCX.

I'l repeat the whole exrcise, starting with dowloading src and hex from same build.

from t-962-improvements.

That’s where I am and I have managed to build, flash with flashmagic and test multiple times with that version.

You should be golden now.

I was also a bit confused as that version seems to have a lot of the latest code revisions in it including the ones for the manual bake screen, but it’s all good.

from t-962-improvements.

I'm unable to test it until tomorrow, but the hex file I built is certainly different in size and content than the one downloaded from here. What are the size and MD5 of your hex file?. Mine is 147046 bytes (147456 bytes on disk) and MD5 is 100A95526E10F34A4914991318E7B4C7. Stats reported at end of (Release) build are
text data bss dec hex filename
51892 372 3084 55348 d834 T-962-Controller.axf

from t-962-improvements.

No, still crashes. The 0.5.1 hex file downloaded from here and flashed into the machine works fine. The 0.5.1 source code compiled with LPCXpresso v8.1.4 with no warnings or errors after changing to GNU99 mode crashes badly. It sticks on the info screen with LEDS and buzzer randomly flashing like crazy.

This works :

T-962-controller.hex (downloaded from last public 5.1 release, works fine)
F:\Downloads
144.42Kbytes
CRC 0xD1F519F4
Flash range : 0x00000000 to 0x0000CD57
Flash used : 51.34 Kbytes (including gaps) 40.11% of an LPC2134
Blocks used : 0, 1, 2, 3, 4, 5, 6, 7, 8

This crashes (info screen, leds and buzzer going crazy)
info screen shows "no version info" on info screen and LPC2134/01 Rev F
Compiled with LPCXpresso v8.1.4 [Build 606] [2016-03-14]
Settings : only GNU99 changed deliberately, does not compile without.

T-962-Controller.hex
F:\DEV\LPCX\Projects\oven\T-962-Controller\Release\T-962-Controller.hex
143.60 Kbytes
CRC 0x541E905
Flash range : 0x00000000 to 0x0000CC27
Flash used : 51.04 Kbytes 39.87% of an LPC2134
Blocks used : 0, 1, 2, 3, 4, 5, 6, 7, 8

I don't know if the lack of Version_GetGitVersion() call and no version in the firmware affects anything?. I also wonder if there are other setting differences that are needed.

from t-962-improvements.

This is my first time using this toolchain, so I'm no expert, but let's try to help you out here.
No the version number should not make any difference, I hard coded mine so it looks better, but it works fine if you just leave it as is.

Attached (below) is an export from my working LCPXpresso system which builds and runs 100%.

Note -

1. I made a few minor changes to this from the main branch, in particular, adding my own profiles into reflow_profiles.c, so don't expect this to be byte to byte comparable with the source on this site.

2. I'm using LCPXpress 8.0.0_526

Try to import and run this. If that doesn't work, you are going to have to recheck you compiler settings or revert to an earlier version of LCPXpresso. I have the install for 8.0.0_526 if you really need it.

Here's the compiler output in case that's any use to you.

08:34:34 **** Incremental Build of configuration Release for project T-962-Controller ****
make -r all
Building file: ../src/io.c
Invoking: MCU C Compiler
arm-none-eabi-gcc -std=gnu99 -DNDEBUG -D__CODE_RED -D__NEWLIB__ -Os -g -Wall -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -flto -ffat-lto-objects -mcpu=arm7tdmi -D__NEWLIB__ -MMD -MP -MF"src/io.d" -MT"src/io.o" -MT"src/io.d" -o "src/io.o" "../src/io.c"
Finished building: ../src/io.c

Building target: T-962-Controller.axf
Invoking: MCU Linker
arm-none-eabi-gcc -nostdlib -Xlinker -Map="T-962-Controller.map" -Xlinker --gc-sections -flto -Os -mcpu=arm7tdmi -u _printf_float -u _scanf_float -T "T-962-Controller_Release.ld" -o "T-962-Controller.axf" ./src/PID_v1.o ./src/adc.o ./src/buzzer.o ./src/circbuffer.o ./src/cr_startup_lpc21.o ./src/crp.o ./src/eeprom.o ./src/i2c.o ./src/import.o ./src/io.o ./src/keypad.o ./src/lcd.o ./src/main.o ./src/max31855.o ./src/nvstorage.o ./src/onewire.o ./src/reflow.o ./src/reflow_profiles.o ./src/rtc.o ./src/sc18is602b.o ./src/sched.o ./src/sensor.o ./src/serial.o ./src/setup.o ./src/systemfan.o ./src/vic.o
Finished building target: T-962-Controller.axf

make --no-print-directory post-build
Performing post-build steps
arm-none-eabi-size "T-962-Controller.axf" ; arm-none-eabi-objcopy -v -O ihex "T-962-Controller.axf" "T-962-Controller.hex" ; # checksum -p LPC2134 -d "T-962-Controller.bin"
text data bss dec hex filename
65536 440 3100 69076 10dd4 T-962-Controller.axf
copy from T-962-Controller.axf' [elf32-littlearm] toT-962-Controller.hex' [ihex]
T-962 Improvments (DE Branch).zip

from t-962-improvements.

Many thanks for your time and help Duncan.

Firstly, I flashed your hex file into the 962A. I showed (A) after the version number and proceeded to work fine on all the screens I tried it on.
Then I put your /src dir, /settings dir, .cproject file and .project file into a clean directory and imported that directory into a project on LPCXpresson v8.1.4 606. It compiled 100% first time, but looked a bit smaller than your code and even the data space was slightly different. I deleted io.o to force a remake with compilation of io.c to match your log :

14:06:07 **** Incremental Build of configuration Release for project T-962-Controller ****
make -r all
Building file: ../src/io.c
Invoking: MCU C Compiler
arm-none-eabi-gcc -std=gnu99 -DNDEBUG -D__CODE_RED -D__NEWLIB__ -Os -g -Wall -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -flto -ffat-lto-objects -mcpu=arm7tdmi -D__NEWLIB__ -MMD -MP -MF"src/io.d" -MT"src/io.o" -MT"src/io.d" -o "src/io.o" "../src/io.c"
Finished building: ../src/io.c

Building target: T-962-Controller.axf
Invoking: MCU Linker
arm-none-eabi-gcc -nostdlib -Xlinker -Map="T-962-Controller.map" -Xlinker --gc-sections -flto -Os -mcpu=arm7tdmi -u _printf_float -u _scanf_float -T "T-962-Controller_Release.ld" -o "T-962-Controller.axf" ./src/PID_v1.o ./src/adc.o ./src/buzzer.o ./src/circbuffer.o ./src/cr_startup_lpc21.o ./src/crp.o ./src/eeprom.o ./src/i2c.o ./src/import.o ./src/io.o ./src/keypad.o ./src/lcd.o ./src/main.o ./src/max31855.o ./src/nvstorage.o ./src/onewire.o ./src/reflow.o ./src/reflow_profiles.o ./src/rtc.o ./src/sc18is602b.o ./src/sched.o ./src/sensor.o ./src/serial.o ./src/setup.o ./src/systemfan.o ./src/vic.o
Finished building target: T-962-Controller.axf

make --no-print-directory post-build
Performing post-build steps
arm-none-eabi-size "T-962-Controller.axf" ; arm-none-eabi-objcopy -v -O ihex "T-962-Controller.axf" "T-962-Controller.hex" ; # checksum -p LPC2134 -d "T-962-Controller.bin"
text data bss dec hex filename
65044 364 3104 68512 10ba0 T-962-Controller.axf
copy from T-962-Controller.axf' [elf32-littlearm] toT-962-Controller.hex' [ihex]

14:06:09 Build Finished (took 2s.480ms)

I don't know if the size change is just different libs or is significant, but I'm afraid when flashed into the same T962A it crashed. Basically, as soon as you push F2 Setup, there is a few hundred mS delay then it goes back to the Info screen, repeatably. Also crashes back to info after when selecting a profile.

from t-962-improvements.

Hi Gitlang,

As I said, I'm really not the right person to ask the fine detail on LCPXpresso, I have only ever used it for this project. Having said that, I can only assume that your issue is somehow with your version of LCPXpresso or somehow one of the setup / build options within.

If you managed to flash my .hex code and get it to run then you have nothing wrong with the programming side of things - obviously. But I swear that .hex was a direct result of compiling the code I sent above.

FWIW, the F2 setup issue was exactly what I had initially and I tracked it down to a WDT issue actually rebooting the device. I got this every time I tried to compile 0.5.1 from the official release page here : https://github.com/UnifiedEngineering/T-962-improvements/releases and was starting to lose faith, but had no trouble when I downloaded from the MASTER branch here : https://github.com/UnifiedEngineering/T-962-improvements and recompiled.

If you want to try with v8.0.0_526 and can't find it online, PM me at duncanellison colnewatercom and I'll put it in a dropbox for you (438Mb)

Hope you figure it out as it's a pretty cool project.

from t-962-improvements.

Watchdog Timer? In the firmware or part of CPU?

I've tried both the above source packs you point to with the dame proble. I'll will have to try removing 8.1.4 and installing 8.0.0 - I got it from their website, they have old builds going back quite a way. What I don't understand is whay I have a lump of binary missing compared to yours. I suppose it could be library issue differences but it just doesn't have that feel to it. Very strange. Is there any way I can do debug over this FTDI lead?.

from t-962-improvements.

dame proble = same problem
whay = why

from t-962-improvements.

I only know it was a WDT issue because if you attach a terminal to the FTDI cable at 115K2, then reboot the oven, you should get the code talking to you.

When I pressed F2, it did an immediate reboot and then gave WDT as the reason. I guess that is something to do with an improper build. But I guess that doesn't help you a lot.

There's discussion about this problem elsewhere on the here, IMHO it's definitely something to do with your build settings.

from t-962-improvements.

Aha. Thanks, I've found the thread about the WDT. Seems to be connected to a small capacitor across the S key, and if it charges/discharges before the initialisation has finished. Huge thanks for the data/debug link info, I did not know about that.

from t-962-improvements.

Interesting - loads of serial information coming back when in setup or bake, very useful, but it wont accept terminal input - just says it doesn't understand it. Also, I don't it's deliberate but the Cold Junction temperature reads as 0.1C and doesn't change even when the machine has warmed up a bit when you wouldnormally see 5C change in cold junction or so. Because it thinks the cold junction is at 0.1C, the temperature control is unhappy in Bake mode. Pull the serial lead, press reset, comes up in info screen then menu screen where it tells me the cold junction is 23.1C, and all is normal.

Now, could this be a problem with your firmware mods ( I believe you rely on MAX31855 chips mostly rather than TC's and cold jucntion sensor) or is it my hardware?. I'm not sure I mentioned, but this is a new 962A built November 2015. Is it possible they have changed some I/O channels I wonder?

from t-962-improvements.

Oops, reopened :)

from t-962-improvements.

"it wont accept terminal input" - It will, but you need to type as fast as a machine ;-) From what I can see the code is not designed to accept human input, I think there are some deficiencies in the Rx routines, but haven't investigated further.

Workaround - Use Coolterm (http://freeware.the-meiers.org) and set line mode (Connection > Options > Teminal > Line Mode = yes). It should work just fine.

Assuming you have successfully installed the 18B20, the cold junction should just work. I'm not using the MAX31855 yet (waiting for parts), but mine works fine in this mode.

In case you are interested, I built a windows program (sorry no Linux / Mac) to control the oven via the serial port you can obtain a copy here
Reflow Controller.zip

from t-962-improvements.

Tried CoolTerm. Still won't work respond to commands, and it doesn't recognise "?" now , so I can't get a list of commands that I can't send!. It received fine though. Just tried it on F2 setup and got a table of temperatures etc, and CJ temp was correct. Yes the 18B20 install was fine, done last week and working except that -0.1C business a fes days ago.

Your program seems to be working well. Right at the start I had one incident where it didn't recognise the command and gave the same error message I was getting with the terminals program. Probably finger trouble as everything works now. Very useful - you just need to increase the field width for the TC reading beneath the big green reflow button as they are getting truncated and written over by the last digit. Eg, It reads TC'-.2 and TC2.1 with only the first vertical half of the 2 rendered.

Now I have to get back to actually being able build a current release. You may be right on compiler settings, but goodness knows what is wrong there.

I see you have left the original README.MD, Makefile, etc files in your root project file. LPCXpresso 8.1.4 only use .cproject and .project ( and presumable .settings contents). It neither uses nor creates Makefile, at least as a permanent file. Has your 8.0.0 version changed Makefile or used it in any way?. I have compared .project, .cproject and .settings/language.settings.xml from your archive with those in my project directory and they are identical. So if it is a settings problem, it means making the settings different beteen the two projects which I find very odd.

from t-962-improvements.

@GitLang Just one thought, if you are still concerned about the code size differences, it just occurred to me that you may be building in 'debug' mode, I'm building in 'release' mode.

Glad you found the program useful. I'm still waiting for parts to build the 4 Ch digital thermocouple board, so my unit is out of action for testing right now.

from t-962-improvements.

No, I'm careful to compare like with like. Code size differences don't mean anything unless they are happening with the same build of the compiler and softwarwe with the same settings. What is of concern is the variable size differing. I can't think of a safe reason for the two compiled programs to have different variable size.

I'm changing tack and trying to get everything working with the GCC eabi compiler just as the source is now intended to be compiled since it was moved away from LPCXpresso, but that is proving a lot more difficult than it should. I also can't find an option for LPC2134 with GCC-EABI and VisualGDB. Then I think OK, linux world uses Eclipse and GCC, I'll do exactly that. Then I realise LPCXpresso is exactly that. Argh!. One of the main problems when moving between compiler setups seem to be syntax of interrupt handling and inline assembly.

Anyway, like you, I'm waiting for hardware, so I'll carry on playing until it arrives. Is it the TC SPI chips you are waiting for?. If so, have you tried requesting samples?.

from t-962-improvements.

Anybody - there are several places in lcd.c where we have code like this

FIO1PIN;
FIO1PIN;
FIO1PIN;
FIO1PIN;
FIO1PIN;
FIO1PIN;
FIO1PIN;
FIO1PIN;

FIO1PIN is defined in LPC214x.h as
#define FIO_BASE_ADDR 0x3FFFC000
#define FIO1PIN (*(volatile unsigned long *)(FIO_BASE_ADDR + 0x34))

so those statements are tantamount to writing
0x3FFFC034;
0x3FFFC034;
0x3FFFC034;
0x3FFFC034;
...
What, if anything, does that do in C ?. Nearby comments suggest it's creating a delay.

Similarly, there is
AD0DR1;
AD0DR2;
in adc.c

I still can't get an LPCXpresso build that works and I'm wondering if it's connected

from t-962-improvements.

Actually, the FIO1PIN; line would be equivalent to *0x3FFFC034; rather than what you posted, so it is equivalent to a read of the pin register, which is probably ok. It probably is used as a delay. Because it accesses a volatile location, it won't be optimized away by the optimizer, so it works well as a short delay.

This is probably not related to your problem...

from t-962-improvements.

Well spotted, I had missed the first * and assumed the header file just had a list of register names as usual, although it seems a obscure way of getting a delay. I agree with, but if you run the C/C++ Code Analysis from Eclipse, it picks out all of those instances as dead code. Also, I can't find any sign of that code is a disassembly, but that's probably me just not having found it. As assembler listing with the C code as comments would tell all, but I'm not familiar enough with this dev kit to know how to do that yet, and the Help is no help. Anyway, it's probably not relevant, thanks for that.

from t-962-improvements.

OK, found out how to make a normal mixed C/asm LST file in LPCXpresso, Just add

arm-none-eabi-objdump.exe -d -S "${BuildArtifactFileName}" > "prog.lst"

to the post-build steps, having made sure there is not a # comment above it.

It looks like the repeated FIO1PIN does make it into the binary, but the generated code varies for debug and release builds, and I am wondering how, in either case, *0x3FFFC034; becomes

DEBUG

FIO1PIN; // Need 320ns of timing margin here
3684:   e59f3218    ldr r3, [pc, #536]  ; 38a4 <LCD_WriteCmd+0x26c>
3688:   e5933000    ldr r3, [r3]
FIO1PIN;
368c:   e59f3210    ldr r3, [pc, #528]  ; 38a4 <LCD_WriteCmd+0x26c>
3690:   e5933000    ldr r3, [r3]

RELEASE

19e8:   e5132fcb    ldr r2, [r3, #-4043]    ; 0xfffff035
19ec:   e5132fcb    ldr r2, [r3, #-4043]    ; 0xfffff035

from t-962-improvements.

OK, I am finally compiling working builds!. Thanks for everybodys patience. I should simply have listed to Duncan way bak near the start of the thread. I uninstalled LPCXpresso 8.1.4.606, cleaned up after it, and installed LPCXpresso 8.0.0.526. I made a project, imported the Master build, set dialect to -GNU99, compiled a Release build, flashed it, and it's working fine :)

I assum 8.1.4 either has a compiler/assembler/linker error, or more likely, there is a library change that is screwing things up. In the oven it shows up mainly as a DABT error followed by a WD reset when pressing almost any key.

So the Issue is still open but there is a workaround.

from t-962-improvements.

:-) Great news.

In celebration, I've created a new version of the controller program for you where you can set the oven type in the options and it will label the TC's appropriately. Enjoy !
Reflow Controller.zip

from t-962-improvements.

Thanks for that Duncan, very useful. The deltas are still truncated and unreadable though, they need a bigger field I think.

So far, the oven is doing great. I've done two boards, one of them with components both sides, and the results are great. I'm seeing a lot of lag behind the profile, particularly on the rise from ambient to soak, and soak to peak. It does tend to lag a bit before cooling, the result is more a shifting of the curve. During rise to soak, I'm seeing anything up to 24C lag, but it's within 1 or 2C by the time it reaches soak. Anyway, I am getting much less yellowing of the flux remnants now, and the joints are great. A lot of that I put down to getting a stencil. The boards are one off for now, but I still think the stencil is money well spent, especially if you can squeeze 3 or 4 boards on one standard stencil size - some of the suppliers quote a fixed price for a max area and max number of pads and don't care too much what you put on the gerber. I didn't know how I was going to register the board to the stencil, so I added the board mounting holes to the stencil, at the same hole size. The holes were 3.2mm. On the PCB they plated down to a little less than that. I found a 1/8th inch precision ground dowel, at 3.175mm m6, was close to perfect and I got fantastic register between stencil and PCB. Highly recommended method for cheap home DIY :)

from t-962-improvements.

Hi all. Duncan, did you get a chance to fix that TC delta display getting truncated (as in above image)?.

The simple reason I was lagging behind the profile so badly on the ramp is because I was trying to heat at 1.5 degC/sec. In practice, the T962A seems to manage about 1.2 or 1.3 degC/sec below 150C and a bit less above. Having changed the profile to 11 degree jump per 10 seconds, soak at 165C for 70 seconds, and a bell shaped peak going from 165C to 215C to 165C in 120 seconds, then cooling to 30C at 470 seconds, it's following it fine.

I just did three 100mm x 50mm boards and they came out great. All the components got wicked into alignment, there's no noticeable difference from the middle to the edge of the 24 sq.in. run, and all solder joints look to be small, clean concave joints with no flux yellowing. Other side tomorrow.

My Multicore syringe has just about run out, and I haven't gathered enough courage to use a Bismuth eutectic on something that actually matters yet. I was lucky enough to find some 600gm (21oz) cartridges of Kester Easy Profile 256 for 25 Euros (28 usd) on ebay but unfortunately the b.i.n auction has ended. Oh, there is a cheap stencil service here

OSH Stencils

from t-962-improvements.

The code should compile ok on a recent gcc-arm-embedded now (as can be seen by the updated Travis-CI auto-build). Not sure why it broke using the 5.x gcc.

from t-962-improvements.

Good morning, can I use this issue again?

I downloaded & built succesfully the code ( git clone & make & make flash ) and I upgraded the oven.
I would like to change build-in profile.
I edited only a single value in a table from 50 to 60 for test here:

I ran into the watchdog problem.

If I change the value from 60 to 50 again and repeat the procedure, the controller will work again.

Tonight I have to do some new tests but I guess the problem is in the numbers on the table.
Do you have any suggestions on what to check?

from t-962-improvements.

I changed arm compiler on my system, I kept "gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2" from:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

Now code compile succesfully!

from t-962-improvements.