Gen 7 2.0 and teacup-arm not working with pronterface or repetier

Hello everyone

I started building a Prusa I3 a couple of weeks ago and I decided to use the Gen7 Board-ARM v2.0 hardware to control it.
I've cloned the gen 7 electronics repository, etched the PCB and soldered all the components as per the assembly page: [reprap-diy.com]

I checked every trace for continuity, also making sure the PCB has no shorts between pins and components. After that, I hooked up an ATX power supply and did the voltage measurements as listed here: [reprap-diy.com]
Everything is looking fine so far.

Next I did the serial loopback test to ensure the MCP2200 is working. I attached a serial terminal and everything looked alright. All characters were echoed back to the PC, so I put the LPC1114 in the socket.

After that, I cloned the teacup master repository.
- I fired up configtool.py and loaded up board.gen7-arm.h and printer.mendel.h
- I modified the steps per meter settings to match my prusa I3 build. I didn't make any changes to the board settings
- I saved config.h and ran make -f Makefile-ARM. The firmware compiled without errors or warnings
- I installed the bootloader jumper and hit the reset button. Next I executed make program. The firmware uploaded without errors.
- I removed the bootloader jumper and hit the reset button again.

So far, so good. Next up, I attached a serial terminal @ 115200 baud. When I press the reset button on the board, I am greeted with "start\nok\n". Yay! It looks alive.

Next up, I started pronterface, set the baudrate to 115200 and tried to connect to the board.
Pronterface now just sits there, saying "connecting..." but nothing happens until I hit the reset button. The UI comes to life, "start" appears in the terminal log on the right hand side, but none of the buttons do anything.
I tried sending some M commands manually through pronterface, but I get no response. The ATX PSU remains in standby mode. Sending the M command to enable the ATX supply does nothing.
I also tried repetier host, but it doesn't do anything either. It says it's doing a "forced connect", but it can't control the printer either.

I'm kind of stuck now, because I'm not sure how to continue debugging this issue.
I'm not getting any errors or other output. It's just sitting there doing nothing.

- The MCU seems to be up and running because it sends the start message when I hit the reset button
- Serial communication seems to be working fine because the bootloader managed to download the firmware without errors.

I didn't make any changes to the firmware, other then setting the steps per mm settings through configtool.

Can anyone help me out?

can you post these files? (board.gen7-arm.h and printer.mendel.h)
I have a couple of these boards up and running and I'll compare the files
to see if anything differs.Its worth a shot..

Quote
Shank man
can you post these files? (board.gen7-arm.h and printer.mendel.h)
I have a couple of these boards up and running and I'll compare the files
to see if anything differs.Its worth a shot..

I have attached the files. The steps/mm values in printer.mendel.h may not make sense for a prusa I3, but that's not important right now.
Can you tell me which commit you're running? Maybe a bug snuk into the master branch recently?

My config.h file looks like this:

// Configuration for controller board.
#include "config/board.gen7-arm.h"

// Configuration for printer board.
#include "config/printer.mendel.h"

Some other things I've discovered last night:
- enabling #define DEBUG in debug.h doesn't give me any extra output. Not even after sending a gcode command
- putting a serial print statement at the start of the for(;; ) loop in mendel.c tells me the loop only runs 3 times.

Seems like I'll be going into full-fledged debug mode soon.

Edited 4 time(s). Last edit at 10/12/2018 01:05AM by TheCrazyInventor.

I pulled your files into the Configtool and saved it as a config.h. and when I tried to compile it a few errors popped up. Here are the files I'm using on my Mendel style printer They compile and upload fine. I don't rely on the firmware to turn my power supply on and off.
I'm not sure of the actual commit number, It was December 2016 when I downloaded the zip file. I tried to attach it here but it was a little too big.

sorry I couldn't be much help on this

Ray

I tried compiling my firmware using your files, but I see no change in behaviour. The firmware compiles and uploads just fine.
I also tried the oct 18 2016 commit (the last commit from 2016), but still no change. All I'm getting is "start\nok\n" when I hit the reset button.

Edit:
I just found out that when I comment out the call to timer_init(), the main loop will keep running. I also receive replies back from the microcontroller when sending M and G commands now. Seems like a timer interrupt is hanging the micro or something...

Edit 2:
I've narrowed it down to this line in timer-lpc.c:

  SysTick->CTRL  = SysTick_CTRL_ENABLE_Msk        // Enable the ticker.
                 | SysTick_CTRL_TICKINT_Msk       // Enable interrupt.
                 | SysTick_CTRL_CLKSOURCE_Msk;    // Run at full CPU clock.

When I comment this line, the mcu keeps running and keeps responding to commands. Obviously nothing is happening because the system tick is disabled...

Edited 3 time(s). Last edit at 10/13/2018 09:14AM by TheCrazyInventor.

what compiler version on what os are you using?

Quote
Dust
what compiler version on what os are you using?

uname -a

Linux AMILO-Pi-2550 4.15.0-29-generic #31~16.04.1-Ubuntu SMP Wed Jul 18 10:19:08 UTC 2018 i686 i686 i686 GNU/Linux

Output of arm-none-eabi-gcc -v

Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../lib/gcc/arm-none-eabi/7.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: /build/gcc-arm-none-eabi-Ubq5Xp/gcc-arm-none-eabi-7-2018q2/src/gcc/configure --target=arm-none-eabi --prefix=/build/gcc-arm-none-eabi-Ubq5Xp/gcc-arm-none-eabi-7-2018q2/install-native --libexecdir=/build/gcc-arm-none-eabi-Ubq5Xp/gcc-arm-none-eabi-7-2018q2/install-native/lib --infodir=/build/gcc-arm-none-eabi-Ubq5Xp/gcc-arm-none-eabi-7-2018q2/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/build/gcc-arm-none-eabi-Ubq5Xp/gcc-arm-none-eabi-7-2018q2/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/build/gcc-arm-none-eabi-Ubq5Xp/gcc-arm-none-eabi-7-2018q2/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/build/gcc-arm-none-eabi-Ubq5Xp/gcc-arm-none-eabi-7-2018q2/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/build/gcc-arm-none-eabi-Ubq5Xp/gcc-arm-none-eabi-7-2018q2/install-native/arm-none-eabi --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Tools for Arm Embedded Processors 7-2018-q3-update' --with-multilib-list=rmprofile
Thread model: single
gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded Processors 7-2018-q3-update)

After some more debugging it appears as if SysTick_Handler() is never being called. Currently trying to figure out why.

I installed the latest commit and had no problem connecting with Pronterface running on both Windows & Raspian.
I think that possibly could rule out any bugs?

Edited 1 time(s). Last edit at 10/13/2018 03:26PM by Shank man.

Quote
Shank man
I installed the latest commit and had no problem connecting with Pronterface running on both Windows & Raspian.
I think that possibly could rule out any bugs?

Could you perhaps upload the .hex file so I can give that a try on my board? Maybe I'm having compiler/linker issues or something like that.

Quote
TheCrazyInventor

Quote
Shank man
I installed the latest commit and had no problem connecting with Pronterface running on both Windows & Raspian.
I think that possibly could rule out any bugs?

Could you perhaps upload the .hex file so I can give that a try on my board? Maybe I'm having compiler/linker issues or something like that.

sure, if you can tell me where it is or go about making one. I not very savy when it comes to these type of things.

Quote
Shank man
sure, if you can tell me where it is or go about making one. I not very savy when it comes to these type of things.

After doing a regular compile (by running the make command in the root teacup folder), there should be a file called teacup.hex. This is the file that will be loaded into the microcontroller.

If I can load up this file and it works, that means there must be something wrong with my compiler.

Thanks I can't believe I didn't see it the first time. This is the one created from the latest commit.
I did not alter the printer or board files.

I hope this works. I can attach my earlier hex file if need be

Quote
Shank man
Thanks I can't believe I didn't see it the first time. This is the one created from the latest commit.
I did not alter the printer or board files.

I hope this works. I can attach my earlier hex file if need be

I just uploaded your hex and it works perfectly! All g-code commands (like setting the hot end temperature and stuff) seem to work, the ATX power supply comes to life and the hotend LED turns on.

Looks like I have some weird compiler issue... Could you please post the output of arm-none-eabi-gcc -v?

I got it to work! I installed an older version of the arm compiler and everything is working fine now. The version I installed is gcc-arm-none-eabi-5_4-2016q3-20160926, which can be found here: [launchpad.net]

Unfortunately, I had to do this on windows as I couldn' t get the old version to install on linux. When using the latest version of the compiler on windows, I get the same problem, so it has to be a compiler bug.

Thanks to everyone (and Shank man in particular) for helping me out!