I hooked up some drivers to my bambino 210E board to start testing the firmware step generation.

When I send a G0/1 command the firmwares stops responding and the motors are blocked but do not move.

The G28 command replies "OK" and brakes the motor, but no movement.

I am currently using a Bambino with the virtual com port firmware, and I'm using a JTAG probe to flash and debug.

Has anyone had this problem?

I've been trying to get the Smoothie2 source to run on the bambino 210e for about the past 2-3 weeks with no luck. The first sign of an issue is when making gcc4mbed, the compilation of the sample programs fail with the error
No rule to make target "../../external/mbed/libraries/mbed/targets/hal/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/s110_nrf51822_8_0_0/s110_nrf51822_8.0.0_softdevice.hex".
However, I can still use BuildShell after the failed compilation.
I'm not sure how much this has to do with gcc4mbed but when following the instructions in Smoothie2Notes on how to flash over USB bootloader, the only available memory is SPIFI, so there is no bank A or B available to flash. After flashing the code to SPIFI through lpcscrypt, there is no communication between my computer and the board. This made me think that something in either gcc4mbed or Smoothie2 might not be right for executing from SPIFI. I do know, however, that the board is functioning and able to run code properly from SPIFI, because I have loaded sample programs from dfusec onto the board, and they have run. I also know that my usb ports are not malfunctioning because I've hooked up my old Azteeg x5 mini and it communicates fine.
The only reason I can think of that this is happening is that the gcc4mbed support for the lpc4330(bambino processor) is possibly only good for the lpc4337(smoothie2 board).

Many thanks in advance for any help.

P.S. I forgot to mention I'm running all of this on my mac air running OSX 10.11. I have also tried the ISP loading technique from your notes, but it failed to load code onto the bambino.

So I got the new source to compile and run, and I noticed that more often than not the Bambino will connect to my computer and show up under /dev/ and then after anywhere from 10-25 seconds, it will disappear from /dev/. When it does this, none of the serial communication applications can connect to it. I had added a few printfs() to the source, so I removed those thinking they might have been causing the issues somehow. Removing these did nothing, so I tried recloning the whole repo and starting from scratch, with no result. The board used to connect successfully and hold a serial communication line one out of every few tries, but now it fails on every try. I've tried switching USB cables, switching USB ports, flashing different file formats (Hex and bin), and don't know where to go from here. Also, when using a simple application(like blinking the lights on the board), the board stays connected to the computer, so I'm pretty sure it isn't an issue on my computer.

I have been trying to work out why my code would not support SPP0 and in particular SPP0_SCK pin which is on P3_0.

After a lot of code research I think that link 65 in libs\Pin.cpp is the issue:

map<int, PinName> pins = {{(0x00<<8)+0,P0_0},{(0x00<<8)+1,P0_1},{(0x01<<8)+0,P1_0},{(0x01<<8)+1,P1_1},{(0x01<<8)+2,P1_2},{(0x01<<8)+3,P1_3},{(0x01<<8)+4,P1_4},{(0x01<<8)+5,P1_5},{(0x01<<8)+6,P1_6},{(0x01<<8)+7,P1_7},{(0x01<<8)+8,P1_8},{(0x01<<8)+9,P1_9},{(0x01<<8)+10,P1_10},{(0x01<<8)+11,P1_11},{(0x01<<8)+12,P1_12},{(0x01<<8)+13,P1_13},{(0x01<<8)+14,P1_14},{(0x01<<8)+15,P1_15},{(0x01<<8)+16,P1_16},{(0x01<<8)+17,P1_17},{(0x01<<8)+18,P1_18},{(0x01<<8)+20,P1_20},{(0x02<<8)+0,P2_0},{(0x02<<8)+1,P2_1},{(0x02<<8)+2,P2_2},{(0x02<<8)+3,P2_3},{(0x02<<8)+4,P2_4},{(0x02<<8)+5,P2_5},{(0x02<<8)+6,P2_6},{(0x02<<8)+7,P2_7},{(0x02<<8)+8,P2_8},{(0x02<<8)+9,P2_9},{(0x02<<8)+10,P2_10},{(0x02<<8)+11,P2_11},{(0x02<<8)+12,P2_12},{(0x02<<8)+13,P2_13},{(0x03<<8)+1,P3_1},{(0x03<<8)+2,P3_2},{(0x03<<8)+4,P3_4},{(0x03<<8)+5,P3_5},{(0x03<<8)+6,P3_6},{(0x03<<8)+7,P3_7},{(0x03<<8)+8,P3_8},{(0x04<<8)+0,P4_0},{(0x04<<8)+1,P4_1},{(0x04<<8)+2,P4_2},{(0x04<<8)+3,P4_3},{(0x04<<8)+4,P4_4},{(0x04<<8)+5,P4_5},{(0x04<<8)+6,P4_6},{(0x04<<8)+8,P4_8},{(0x04<<8)+9,P4_9},{(0x04<<8)+10,P4_10},{(0x05<<8)+0,P5_0},{(0x05<<8)+1,P5_1},{(0x05<<8)+2,P5_2},{(0x05<<8)+3,P5_3},{(0x05<<8)+4,P5_4},{(0x05<<8)+5,P5_5},{(0x05<<8)+6,P5_6},{(0x05<<8)+7,P5_7},{(0x06<<8)+1,P6_1},{(0x06<<8)+2,P6_2},{(0x06<<8)+3,P6_3},{(0x06<<8)+4,P6_4},{(0x06<<8)+5,P6_5},{(0x06<<8)+6,P6_6},{(0x06<<8)+7,P6_7},{(0x06<<8)+8,P6_8},{(0x06<<8)+9,P6_9},{(0x06<<8)+10,P6_10},{(0x06<<8)+11,P6_11},{(0x06<<8)+12,P6_12},{(0x07<<8)+0,P7_0},{(0x07<<8)+1,P7_1},{(0x07<<8)+2,P7_2},{(0x07<<8)+3,P7_3},{(0x07<<8)+4,P7_4},{(0x07<<8)+5,P7_5},{(0x07<<8)+6,P7_6},{(0x07<<8)+7,P7_7},{(0x08<<8)+8,P8_0},{(0x09<<8)+0,P8_1},{(0x09<<8)+1,P8_2},{(0x09<<8)+2,P8_3},{(0x08<<8)+4,P8_4},{(0x08<<8)+5,P8_5},{(0x08<<8)+6,P8_6},{(0x08<<8)+7,P8_7},{(0x09<<8)+0,P9_0},{(0x09<<8)+1,P9_1},{(0x09<<8)+2,P9_2},{(0x09<<8)+3,P9_3},{(0x09<<8)+4,P9_4},{(0x09<<8)+5,P9_5},{(0x09<<8)+6,P9_6},{(0x0A<<8)+1,PA_1},{(0x0A<<8)+2,PA_2},{(0x0A<<8)+3,PA_3},{(0x0A<<8)+4,PA_4},{(0x0B<<8)+0,PB_0},{(0x0B<<8)+1,PB_1},{(0x0B<<8)+2,PB_2},{(0x0B<<8)+3,PB_3},{(0x0B<<8)+4,PB_4},{(0x0B<<8)+5,PB_5},{(0x0B<<8)+6,PB_6},{(0x0C<<8)+1,PC_1},{(0x0C<<8)+2,PC_2},{(0x0C<<8)+3,PC_3},{(0x0C<<8)+4,PC_4},{(0x0C<<8)+5,PC_5},{(0x0C<<8)+6,PC_6},{(0x0C<<8)+7,PC_7},{(0x0C<<8)+8,PC_8},{(0x0C<<8)+9,PC_9},{(0x0C<<8)+10,PC_10},{(0x0C<<8)+11,PC_11},{(0x0C<<8)+12,PC_12},{(0x0C<<8)+13,PC_13},{(0x0C<<8)+14,PC_14},{(0x0D<<8)+0,PD_0},{(0x0D<<8)+1,PD_1},{(0x0D<<8)+2,PD_2},{(0x0D<<8)+3,PD_3},{(0x0D<<8)+4,PD_4},{(0x0D<<8)+5,PD_5},{(0x0D<<8)+6,PD_6},{(0x0D<<8)+7,PD_7},{(0x0D<<8)+8,PD_8},{(0x0D<<8)+9,PD_9},{(0x0D<<8)+10,PD_10},{(0x0D<<8)+11,PD_11},{(0x0D<<8)+12,PD_12},{(0x0D<<8)+13,PD_13},{(0x0D<<8)+14,PD_14},{(0x0D<<8)+15,PD_15},{(0x0D<<8)+16,PD_16},{(0x0E<<8)+0,PE_0},{(0x0E<<8)+1,PE_1},{(0x0E<<8)+2,PE_2},{(0x0E<<8)+3,PE_3},{(0x0E<<8)+4,PE_4},{(0x0E<<8)+5,PE_5},{(0x0E<<8)+6,PE_6},{(0x0E<<8)+7,PE_7},{(0x0E<<8)+8,PE_8},{(0x0E<<8)+9,PE_9},{(0x0E<<8)+10,PE_10},{(0x0E<<8)+11,PE_11},{(0x0E<<8)+12,PE_12},{(0x0E<<8)+13,PE_13},{(0x0E<<8)+14,PE_14},{(0x0E<<8)+15,PE_15},{(0x0F<<8)+1,PF_1},{(0x0F<<8)+2,PF_2},{(0x0F<<8)+3,PF_3},{(0x0F<<8)+5,PF_5},{(0x0F<<8)+6,PF_6},{(0x0F<<8)+7,PF_7},{(0x0F<<8)+8,PF_8},{(0x0F<<8)+9,PF_9},{(0x0F<<8)+10,PF_10},{(0x0F<<8)+11,PF_11}};

I have not systematically compared this with the LPC4330 chip itself, before I embark on this exercise, am I correct in this assumption?

Note: I realise that I should change to a 'channel' approach as used in max31855.cpp, which for the LPC4330 is:

SPI1_SSEL   P1_5
SPI1_MOSI   P1_4
SPI1_MISO   P1_3
SPI1_SCK    PF_4
SPI0_SSEL   P1_0
SPI0_MOSI   P1_2
SPI0_MISO   P1_1
SPI0_SCK    P3_0

And I think I need a method of changing from 16bit mode to 8 bit mode to support different devices and I probably need to introduce mutexes to ensure they are thread safe for a proper RTOS implementation too.

I am wondering if I should create a wrapper for an SPI object that deals with all these issues so future processor ports will be simpler, not to mention different usage for the same peripheral?

Cheers
Douglas

Hi,
I have a Bambino 200E and am able to compile the current Smoothie2. When I look in the Kernel I see that it starts this->serial = new SerialConsole(P3_4, P3_5, 9600) I'm trying to work out where P3_4 and P3_5 end up on the Bambino. Looking at the Bambino pin aliases XLS here http://wiki.micromint.com/index.php/Bambino_Documentation I don't see these pins. I tried hooking up to UART0_RX and UART0_TX at 9600 but Pronterface just says "Connecting....." forever. I've tried looking at the schematic http://www.micromint.com/updates/bambino/SCH-BAM200-B.pdf I see the pins labeled P3_4 and P3_5 but I can't work out how these map to the gadgeteer ports.
I'm updating the bambino using:
boot_lpcscrypt
lpcscrypt program ./LPC4330_M4/Smoothie2.hex SPIFI

Should that be the bin file I flash? I get no leds after flashing either file. I can flash the demo blink file using lpcscrypt so that part seems to be working.
What should I try next?

I have now made a lot of updates, and will be looking to issue a pull request on or before Monday.

Note my code has already been merged with #34 and is current with Smoothie v2 and includes most of the non USB/Ethernet/SD-card functionality.

I need to confirm why the recent changes still do not enable homing, some weird Rotary Delta behaviour and to then test the Z-Probing and I am good to go.

There is no updates on blog nor this repo December 2016.
I'm very scared that Smoothieboard 2 never gonna see the sunlight.

This is to document the issue and to cover off its resolution.

Issue: The endstops are not triggered during G28 Home.

Scenario: Using a FirePick Rotary Delta and the latest Smoothie2 code base, SilentStepStick at 256 microsteps and 400 step stepper motor.

Investigation:
(1) Using GDB and Segger's JLink I have determined that the loop in 'wait_for_homed' method gets executed only once despite having a endless loop that only exits when 'running' becomes false. It never gets back to the 'while' statement to go repeatedly until it detects the endstop(s) are triggered. Sometimes it only gets as far as the 'THEKERNEL->call_event(ON_IDLE);' statement and never returns to the 'wait_for_homed' code at all.
(2) I am wondering if Smoothie is not able to generate the step rate of some 102400 pulses per revolution for the configuration I have, and therefore does not have enough capacity to run all the other 'tasks' as the interrupt rate could be very rather high for the StepTicker.
(3) Options:
(a) Substantially reduce the resolution of the StepperMotor to (say) 16 microsteps to see if it now works; if this is the case the consider the following:
(i) Migrate the endstops code to use interrupts on the endstop pins rather than polling them, this would include the debounce feature; I have done this for other real-time motor control systems as I have found polling to be too problematic at high work loads. I Note that the MBED interrupt feature for PIN may be too heavy and I may need to write my own ISR to keep it as fast as possible.
(ii) Consider migrating the Step generation and enstops code to the M0 processor, but note that it does not appear to have a SysTick timer on that core.
(iii) Consider moving the endstop code into the StepTicker code so that each time a stepper motor is sent a pulse, the endstop is checked (either the pin itself polled, or a flag set by an interrupt from the pin)
(b) Implement Segger's SystemView code analyser to obtain actual metrics for time spent in interrupts and how often they are occurring (I am part of the way through this but I cannot get the SystemView application to connect to the Smoothie2 target, need too resolve this).

Thoughts?

Cheers
Douglas