chipKIT® Development Platform

Inspired by Arduino™

chipKIT uC32 with Dragino YUN shield

Created Sun, 21 Feb 2016 05:39:05 +0000 by ltheoret

ltheoret

Sun, 21 Feb 2016 05:39:05 +0000

Hi,

I have been working with the chipKit family of board since about the start of Dec 2015. I have 2) uC32, 1) WF32 and 1) WiFire. I have been working a lot with the WF32 developing a web server, This seemed counter productive as that is not my cup of tea. (I also have 4- Infiduino wich are Arduino Uno R3 clones for testing new hardware). I both a Dargino YUN shield. This was to test with the uC32. Well the good news is that the bridge seams to be working with it so far. I can read and control the chipkit from the YUN shield. Now to do my homework, to see if I can program the chipkit through the YUN shield.

Currently to program the chipkit I have to remove the YUN shield from the board, program it using USB then plug the shield back in. I have a Leonardo and a DUE on order. the Leonardo was a mistake oops. Since the bridge works with the chipkit with no modifications the DUE was a mistake too. Dragino YUN shield manual says the DUE is not compatible with the bridge.

Luc

majenko

Sun, 21 Feb 2016 11:44:15 +0000

Nice board. I wasn't aware that existed. I have just ordered one from Swizerland - probably take a while to get to me, but that's the closest I could find...

It should be perfectly possible to program the chipKIT from the OpenWRT side of things. The two main problems are auto-resetting the board, which can probably be done through a GPIO the same as Arduino boards, and running pic32prog or avrdude to do the programming. That latter is the hardest point...

We do not have a precompiled MIPS Linux binary of pic32prog as yet, and the newer versions (6+) versions of avrdude cannot cope with the pic32 address range. So cross-compiling pic32prog using the OpenWRT cross-compiling tools will be needed. That is something I will be tackling when my Yun shield arrives, but I can start looking with my normal Yun before then.

Once that has all been tackled you can use UECIDE to remote program in just the same way as the Yun or chipKIT Pi, through SSH. There are Pi scripts that can be adapted here: https://github.com/UECIDE/ckpi-support

Sent from my SM-T555 using Tapatalk

majenko

Sun, 21 Feb 2016 19:39:54 +0000

I have started building the OpenWRT "buildroot" system (cross compiler environment) for the Yun. It may take a while... Once that is done I will look at building pic32prog with it.

nroff-man

Sun, 21 Feb 2016 21:25:01 +0000

Hi

My pic programmer for all PICMicros which includes the PIC32 has been working well on OpenWRT for some years already.

See this page (for an example of how to do this): http://wiki.kewl.org/dokuwiki/boards:wr841nd

The STK500v2 compatible loader tool named `pload' should also work and will program via a serial interface. USB serial has not been tested on OpenWRT though.

Bye

ltheoret

Sun, 21 Feb 2016 22:34:30 +0000

Hi,

To get the YUN shield to program all they did was include the file attached to the: Arduino/hardware/Arduino/avr/board.txt

majenko

Sun, 21 Feb 2016 22:47:02 +0000

Yeah, but it programs Arduino boards through the ICSP header directly, with no bootloader installed. That can't be done with chipKIT boards, since the ICSP header isn't, and avrdude wouldn't be able to work with it anyway if it was.

The programming has to happen through the serial port using the bootloader and the proper pic32 tools - i.e., pic32prog or something similar. And that means compiling those tools for the right architecture. And that is proving somewhat arduous at the moment as I have just found that I have compiled my OpenWRT environment for the wrong libc - they seem to have changed from uClibc to musl as the default :( I don't know what version the Yun shield you have uses, but my Yun use uClibc.

nroff-man

Sun, 21 Feb 2016 23:09:17 +0000

lo

the easiest way to create a cross compiler is to build an image for openwrt.

for example, for my wr841 which was built in jan:

root@wr841:/usr/bin# uname -a Linux wr841 4.1.15 #3 Tue Jan 19 13:15:06 GMT 2016 mips GNU/Linux

root@wr841:/usr/bin# ldd pload /lib/ld-musl-mips-sf.so.1 (0x5570a000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x77a6a000) libc.so => /lib/ld-musl-mips-sf.so.1 (0x5570a000)

i can cross compile from Linux using a custom make file utilising the tool chain used to make the firmware.

Eg. export STAGING_DIR = /embedded/openwrt/openwrt.git/staging_dir COMPILE = $(STAGING_DIR)/toolchain-mips_34kc_gcc-5.2.0_musl-1.1.11/bin/mips-openwrt-linux- AS = $(COMPILE)as LD = $(COMPILE)ld CC = $(COMPILE)gcc

This PIC18 boot loader project: http://hg.kewl.org/pub/wellington/ contains a subdir called `loader' where i build a binary for the router and run it via an NFS mount.

This should be enough information.

bye

majenko

Sun, 21 Feb 2016 23:25:40 +0000

Yeah, I know, and that is exactly what I am doing. Except thanks to OpenWRT what I had spent the afternoon compiling is no good.

I also have a separate toolchain (mips-linux-uclibc) which I know will create the right binaries for me, except I can't get it to compile the pre-requisite libraries that I need to get libusb and libusb-1.0 to compile so I can then compile pic32prog.

Well, OpenWRT thinks it's compiling "toolchain-mips_34kc_gcc-5.2.0_uClibc-1.1.12" at the moment, which if it succeeds (it failed just now with infinite symbolic link depth errors) it might finally allow me to compile the libraries I need...

nroff-man

Sun, 21 Feb 2016 23:38:36 +0000

lo

why do you even need libusb?

i don't know much about the uC32 but it looks like an FTDI which should be ttyUSB or whatever in Linux.

the solution to this already exists using the `pload' shown in the previous posts.

bye

majenko

Sun, 21 Feb 2016 23:58:51 +0000

libusb is required by pic32prog. pic32prog is the tool that we use.

majenko

Mon, 22 Feb 2016 00:02:46 +0000

And anyway, it has nothing to do with the FT232R chip. Read what the Yun shield is. There is no USB connection to the board. It's direct to the UART pins. So it will be /dev/ttyATH0, plus GPIO mashing to get the board to reset to enter the bootloader - and I have no clue which GPIO yet (but probably GPIO18) until I get one of these shields in my hand.

nroff-man

Mon, 22 Feb 2016 00:42:16 +0000

lo

looks to me like pic32prog needs some means to disable support for unwanted back-ends. the main issue is target.c which needs work in that area.

btw, the (c) header in executive.c doesn't look legit. i have never seen the hex files with that header.

bye

nroff-man

Mon, 22 Feb 2016 00:43:51 +0000

hi

i see now, the uc32 has a method to disable the FTDI and program via pins?

on the WR841 the main uart is an 8250 compatible, there is an atheros uart in there as well and I seem to remember you enable using the equivalent of PPS.

bye

majenko

Mon, 22 Feb 2016 00:46:51 +0000

lo looks to me like pic32prog needs some means to disable support for unwanted back-ends. the main issue is target.c which needs work in that area.

But then you wouldn't be able to slip in a pickit2 and burn a bootloader with that on the same Yun shield.... btw, I have put in a request for pic32prog to have Linux GPIO ICSP bit-banging added, which would be very useful.

majenko

Mon, 22 Feb 2016 00:48:41 +0000

hi i see now, the uc32 has a method to disable the FTDI and program via pins? on the WR841 the main uart is an 8250 compatible, there is an atheros uart in there as well and I seem to remember you enable using the equivalent of PPS. bye

You don't disable the FTDI, you just don't use it. The FTDI acts as a bridge between the USB and the main UART on the PIC32. You can just talk direct to the UART through the UART pins. As long as there is a way to trigger a reset so that the bootloader runs you can then run pic32prog through the UART connection to program via the bootloader.

And of course all that needs to be performed via SSH from UECIDE...

nroff-man

Mon, 22 Feb 2016 00:55:20 +0000

lo

afaik pic32prog supports ICSP already, there is the bitbang back-end.

my own tools support all PICMicros on openwrt, something like 918 devices in total except a number of those require high voltage so are more difficult to use.

a linux kernel module has been written to speed up ICSP on openwrt and it would be sensible to utilise that if more speed is demanded.

http://wiki.kewl.org/dokuwiki/projects:gpio-bb

bye

majenko

Mon, 22 Feb 2016 01:38:25 +0000

From what I could fathom of the bitbang backend it operates through a UART, not through GPIO.

I am making progress... My problem now though is that the Yun (at least mine, I don't know if new ones do or not) runs uClibc 0.9.33.2, but the oldest uClibc that seems to be actually available is 1.0.0, so although I have managed now to compile properly it's not running because it's looking for so.1 versions of libraries instead of so.0, which is somewhat sucky...

I have made those that I can static (for testing for now), but (besides not being good) OpenWRT seems to not want to install a static libudev.a ...

majenko

Mon, 22 Feb 2016 01:48:43 +0000

Ah, I see what they have done. There's two uClibc's around - uClibc.org and uClibc-ng.org. OpenWRT seem to be unable to make up their mind what they are using. They went from uClibc to uClibc-ng to musl. I have now manually changed the uClibc package source to the original one, and I hope it will build 0.9.33.2 for me...

majenko

Mon, 22 Feb 2016 01:58:57 +0000

Oh, and rather than messing with special cross-compiling-enabled makefiles I have set up a proper OpenWRT package so you can go "make package/pic32prog/compile" and it downloads the source, patches it, installs the dependencies and compiles and installs pic32prog. You can even make a package for opkg with it. It even shows up in "make menuconfig" as a package you can compile and install by default...

... if only it would execute ;)

ltheoret

Mon, 22 Feb 2016 04:17:24 +0000

Hi, I went to Dragino website and downloaded the latest openWRT it is called: "dragino2-yun-common-v2.0.7-squashfs-sysupgrade.bin" on a separate website I found some people with other Iduino YUN shield were having problems and they flashed there's with this from Dragino and fixed there problems.

I was looking at the way the compilers are setup and noticed it was not as easy as I hoped. This is above my head. For now I can live with unplugging the boards to program. Just takes a long time to boot with a USB stick plugged in.

Luc

majenko

Mon, 22 Feb 2016 09:51:21 +0000

No dice getting the older uClibc to compile. I think I am going to have to trawl through the git commits looking for a version that has that uClibc in it. Could take some time...

Sent from my SM-T555 using Tapatalk

majenko

Mon, 22 Feb 2016 10:20:18 +0000

Ok, a quick grep has shown me commit number ff155ca5fbf218ff55e81f4f16041cefc413f348 which might do the job. It's certainly building for "mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2" which is a very good sign...

majenko

Tue, 23 Feb 2016 15:29:12 +0000

Ok, I have my Dragino Yun shield now, and very nice it is too.

I can confirm that it is indeed still on uClibc-0.9.33.2 just like my existing Yun. And while I have made a crosscompiling environment, it just doesn't want to work. Errors with pthread saying it has multiple definitions, which isn't good. I am just starting a complete clean recompile of the toolchain to see if that helps matters, but probably not.

majenko

Tue, 23 Feb 2016 16:37:14 +0000

Ok, no different. Right, on to the next plan, which I have chosen to call Preparation H.

That is, let's try building the Linino fork and see if that will work.

Anyone for Icecream?

ltheoret

Wed, 24 Feb 2016 00:46:44 +0000

Hi,

I just notice last night the Arduino TIAN. It is a Arduino 101 with a YUN and 4Gb module all in one. This yun shield and an uC32 is still better just add a jump drive (USB stick).

Luc

majenko

Wed, 24 Feb 2016 09:09:41 +0000

Well, linino is the way to go. However I have had to make major changes to pic32prog to make it modular so I can disable the adapters that aren't needed so that it will compile.

Still, I have a binary that executes on the yun now. However I can't get the serial to work at all. Not sure why. It's just doing nothing. I can get data out, but nothing seems to come back in. Investigations are continuing...

Sent from my SM-T555 using Tapatalk

majenko

Wed, 24 Feb 2016 11:19:39 +0000

Wayhay! Somehow I managed to brick my Dragino :)

Kernel panic when booting. Nice. No idea why. I can only think it will have been one of two things - since those are the only things I have done - installation of "udev" or installation of "pic32prog". My guess is the former.

Still, I now know all there is to know about re-flashing the ms14 module from Linux. I'll make myself a little blog post about it I think so I can find it next time I need it. (By the way, the instructions on the Dragino wiki are out of date).

majenko

Wed, 24 Feb 2016 14:42:10 +0000

Well, that was an interesting ride.

First some things I have discovered:

  1. You cannot use the UART if the USB connection (FT232) is plugged in on your chipKIT board.
  2. There is a way of disabling the Dragino's UART connection so you can program the chipKIT without having to unplug the Dragino:
# Disable the UART
echo 0 > /sys/class/gpio/gpio24/value
# Enable the UART
echo 1 > /sys/class/gpio/gpio24/value
  1. There is a login running by default on the UART which is needed for the Bridge to work.
  2. The Dragino is big-endian, and pic32prog only works on little-endian machines.
  3. There is no reset connection to the 6 pin SPI header on the chipKIT boards like there is on the Arduino boards.

So after finding out all that, and fixing what can be fixed, and scripting to work with what can't, I have finally managed to program Blink to my WF32 direct from the Dragino! It's a miraculous feat it has to be said...

So what you want to do is install my specially customized version of pic32prog, which also includes a programming script:

root@dragino:~# opkg install http://uecide.org/pic32prog_2.0.189-f2988c6_ar71xx.ipk

Then you can upload a .hex file using scp to the Dragino, and program it:

root@dragino:~# run-pic32prog Blink.hex 
Programmer for Microchip PIC32 microcontrollers, Version 2.0
    Copyright: (C) 2011-2015 Serge Vakulenko
      Adapter: STK500v2 Bootloader
 Program area: 1d000000-1d1fffff
    Processor: Bootloader
 Flash memory: 2048 kbytes
  Boot memory: 80 kbytes
         Data: 6212 bytes
        Erase: done
Program flash: ######### done
 Verify flash: ######## done
 Program rate: 3058 bytes per second

Now to see about automating it with UECIDE...

majenko

Wed, 24 Feb 2016 18:19:56 +0000

Here's a blog post all about it:

https://hackingmajenkoblog.wordpress.com/2016/02/24/dragino-chipkit-yun-yum-yum/

ltheoret

Thu, 25 Feb 2016 05:03:09 +0000

Hi,

I did not expect that you would have something so quick. I will try it tomorrow. had a long day at work. But you can actually program the ChipKit from the Yun Shield. I was worried it was not possible.

Luc

ltheoret

Thu, 25 Feb 2016 16:14:54 +0000

Hi,

You say to wire the RESET pin on the 6-Pin SPI header to the RESET pin in power section on the YUN shield. Is this pin 2 on the WF32 schematic? Would it not be better to wire this on the ChipKIT board? If this pin is not wired on the ChipKIT board would not make sense to do it there and make the YUN more compatible with other board?

Luc

ltheoret

Thu, 25 Feb 2016 16:36:40 +0000

Hi,

Oh! that is pin 5 on the SPI header, the SS pin. There is no connection on ChipKIT, the header is not loaded.

Luc

majenko

Thu, 25 Feb 2016 16:56:40 +0000

Hang on, I might be getting my pins mixed up here...

majenko

Thu, 25 Feb 2016 17:04:48 +0000

No I'm not. Yes, that is the SS pin on the chipKIT boards, which is where the RESET pin is on Arduino boards.

The Dragino has GPIO18 connected to that pin and is used to reset the target MCU. Just one more small difference with the Digilent boards that makes you ask "Why on earth...?"

That pin should be reset. Someone at Digilent decided that it shouldn't be, so the Digilent boards don't have RESET, they have SS. So you need to somehow link that to RESET. That can either be on the Dragino, as I did since it is incredibly simple - a single Dupont male-female jumper is all you need - or you can do it on the chipKIT board if you prefer, it makes no difference.

Another option is to find a different GPIO pin on the Dragino that can be re-wired to do the job of toggling reset, though I don't see anything that looks promising on that front.

All Arduino boards have the SPI reset wired to the power reset, so having the wire in place on the Dragino will make absolutely no difference. By doing it on the Dragino you are increasing the compatibility with boards. If you did it to the chipKIT you would have to then do it with any other chipKITs you might want to use with the Dragino.

majenko

Thu, 25 Feb 2016 17:11:22 +0000

Another option, though one that breaks the bridge functionality, is to use a USB connection between the Dragino and the chipKIT board. You require a couple of extra kernel modules (that I am just working on packaging up) but it does work.

I have found that sometimes the UART connection doesn't always program - it looks like there's something there that is making it a bit "iffy" - maybe the UART login stuff not killing fast enough or something...?

majenko

Thu, 25 Feb 2016 17:26:56 +0000

FTDI drivers for the Dragino: http://uecide.org/ftdi_1.0.0_ar71xx.ipk

ltheoret

Thu, 25 Feb 2016 18:05:57 +0000

Hi,

Thank you for your prompt reply. I have wired the Dragino as you said. did all the steps in your link above. this is the error I get in UECIDE.

Compiling... • Compiling sketch... • Compiling core... ‣ api • Compiling libraries... • Linking sketch... Compiling done. Memory usage • Program size: 6096 bytes • Memory size: 492 bytes • Compilation took 0.614 seconds Uploading firmware... Uploading firmware image... com.jcraft.jsch.JSchException: java.net.ConnectException: Connection refused: connect at com.jcraft.jsch.Util.createSocket(Util.java:349) at com.jcraft.jsch.Session.connect(Session.java:215) at com.jcraft.jsch.Session.connect(Session.java:183) at org.uecide.builtin.scp.main(scp.java:86) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.uecide.Context.runBuiltinCommand(Context.java:802) at org.uecide.Context.executeCommand(Context.java:540) at org.uecide.Context.executeKey(Context.java:485) at org.uecide.Context.executeUScript(Context.java:618) at org.uecide.Context.executeKey(Context.java:480) at org.uecide.Sketch.programFile(Sketch.java:3401) at org.uecide.Sketch.upload(Sketch.java:1650) at org.uecide.Editor$DefaultRunHandler.run(Editor.java:184) at java.lang.Thread.run(Unknown Source) Caused by: java.net.ConnectException: Connection refused: connect at java.net.DualStackPlainSocketImpl.connect0(Native Method) at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source) at java.net.AbstractPlainSocketImpl.connect(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.<init>(Unknown Source) at java.net.Socket.<init>(Unknown Source) at com.jcraft.jsch.Util.createSocket(Util.java:343) ... 16 more

I was trying to upload the BLINK demo. I installed the pic32Prog_2.0... and it said it configured. Then I copied the chipkit.service as directed. Modified the board.txt for both the ChipKIT uC32 and WF32 boards rebooted everything, then tried uploading the sketch. Am I missing a step? It says "connection Refused".

Under Hardware->Device it is blanc Under Hardware->Programmers I selected "Upload via Dragino YUN shield at" then here is noting after the at. When I try to upload it does ask for a password.

I tried this with both the WF32 and the uC32, same error.

So how do I get a blink.hex file that I cam manually upload?

Luc

majenko

Thu, 25 Feb 2016 18:21:27 +0000

The problen is that it's not finding the dragino with mdns. It is a bit shaky at the moment.

You can manually specify an ip jn thd sketch itself with

#pragma parameter ip=192.168.0.21

Or you can use the hostname:

#pragma parameter ip=dragino-43af7h.local

Sent from my SM-T555 using Tapatalk

ltheoret

Thu, 25 Feb 2016 18:23:12 +0000

Ho,

OK. Loading the .hex file manually works as advertised. But UECIDE does not. Half way there. :)

Luc

ltheoret

Thu, 25 Feb 2016 18:33:19 +0000

Hi, well! the "#pragma parameter ip=mydragino-01" did it :D . Work like a charm.

Luc

ltheoret

Thu, 25 Feb 2016 18:52:40 +0000

Hi,

Tested this on both the ChipKIT wf32 and uC32, work well. Tested it with the WiFire, works too. With the WiFire the Dragino Shield cannot read the USB. tried it more than once, no SD. interesting.

Luc

ltheoret

Thu, 25 Feb 2016 19:18:40 +0000

Hi,

One more comment. In the Service->chipkit.service file. there is a board id, majenko calls it wf32 I call it uC32. then in the UECIDE board.txt files you need this to match. well for the WF32, uC32 and WiFire boards I changed them all to uC32 as I realised it identified the family of boards not the model of board.

I do not recommend using this with the WiFire, it disables the USB on the Dragino shield. I do not need the WiFire with the Dragino. I was just testing to see if it would work. my concluding is: do not use it with the WiFire.

Luc

ltheoret

Thu, 25 Feb 2016 19:39:21 +0000

A big thank you to majenko for getting this up and running so fast.

Luc

ltheoret

Thu, 25 Feb 2016 22:26:44 +0000

Hi,

I left the YUN-uC32 board running with just the blink demo running. Now I tried to up load a MySQL example I am working on, and the board refused to upload the sketch. So I changed uC32 boards and I uploaded the MySQL demo with no problem. but now I want to use the Blink example again mot to flood my my database with random data. This is the error I get:

Compiling... • Compiling sketch... • Compiling core... ‣ api • Compiling libraries... • Linking sketch... Compiling done. Memory usage • Program size: 6096 bytes • Memory size: 492 bytes • Compilation took 0.634 seconds Uploading firmware... Uploading firmware image... Programming target... Programmer for Microchip PIC32 microcontrollers, Version 2.0 Copyright: (C) 2011-2015 Serge Vakulenko Adapter: STK500v2 Bootloader Program area: 1d000000-1d1fffff Processor: Bootloader Flash memory: 2048 kbytes Boot memory: 80 kbytes Data: 6096 bytes Erase: Cannot enter programming mode. Done

'Cannot enter programming mode' or uC32 just hangs with the LD 4 status light blinking like crazy and the LD5 solid on, when that happens UECIDE hangs. Rebooting the Linux or the uC32 does not help.

Do I Have to close and open UECIDE between each sketch. could it because I have 2 UECIDE open at the same time, because now it works again.

When I cycle the power on the boards everything works again. I will try to only have one instance open at a time.

Luc

ltheoret

Thu, 25 Feb 2016 23:08:48 +0000

Hi,

I think it is the run-pic32prog in the YUN shield that is getting stuck. I invoked it with no command line parameters and it did the same, got stuck, with the lights flashing like above. Reboot Linux and then the uC32 and recovered.

Luc

majenko

Thu, 25 Feb 2016 23:36:31 +0000

Yes, I have experienced this as well. There is something about the UART connection that it doesn't much like. I have a feeling that the level shifter for the UART is getting confused. It's supposed to automatically sense the direction of the signals, and I think it's maybe a little too sensitive sometimes and getting stuck in the wrong direction.

It would be nice to try bypassing that UART level shifter, since it shifts from a source voltage of 3.3V (the SPI shifter goes from 2.5V, but the UART is already shifted to 3.3V inside the HE module) and see if that improves things. I need to check which pins on the HE are the UART and solder some wires in to there - there's no way I can do it on the shifter chip ;)

Either that or there's something intercepting the data when it shouldn't. Either way it's causing a breakdown in the bootloader protocol which confuses everything.

At the moment I am working on a board that uses the USB variant of the bootloader, so it's not touching those UART pins at all, and it's working 100% reliably.

On a side note: I think I am going to bundle my FTDI drivers, my pic32prog and scripts, and the CDC/ACM drivers as well into one big "chipKIT" package to make it easier to install everything at once.

ltheoret

Thu, 25 Feb 2016 23:42:38 +0000

Hi,

Still having issues. I think the problem is with the uC32 board. I cannot get it to program any more. Even after removing the power and restarting. This is what I get when I try to use the program directly in the Dragino shield.

BusyBox v1.19.4 (2015-01-06 10:25:28 CST) built-in shell (ash) Enter 'help' for a list of built-in commands.

| _ | _ \ / \ / | | \ | |/ _
| | | | |) | / _ | | _ | || | | | | | | || | _ < / ___ \ || || || |\ | || | |/|| _// __||| _|___/ W i F i, L i n u x, M C U, E m b e d d e d Model: Dragino v2 Version: Dragino-v2 common-2.0.7 Build Tue Nov 24 19:39:50 CST 2015 www.dragino.com

root@MyDragino-01:~# cd .. root@MyDragino-01:/# cd mnt root@MyDragino-01:/mnt# cd sd root@MyDragino-01:/mnt/sda1# ls $RECYCLE.BIN System Volume Information data BLINK-uC32.hex arduino mysql.py root@MyDragino-01:/mnt/sda1# run-pic32prog BLINK-uC32.hex Programmer for Microchip PIC32 microcontrollers, Version 2.0 Copyright: (C) 2011-2015 Serge Vakulenko Adapter: STK500v2 Bootloader Program area: 1d000000-1d1fffff Error setting parameter 70 root@MyDragino-01:/mnt/sda1#

The same error I was getting from UECIDE.

Luc

ltheoret

Thu, 25 Feb 2016 23:50:32 +0000

Hi majenko,

Yes from all the info I been reading on the YUN shield, it is very sensitive to the UART. I look forward to a chipKIT package. Would that include hardware or just software?

Luc

ltheoret

Fri, 26 Feb 2016 00:22:12 +0000

I was reading and in order to make tis work, I think I will have to remove R1 and R2 from the UC32 board, it is the same for the wf32 board. The problem is, the resistors are so tiny. If I get them off, they will be off permanently. I will try but I ran out of time, next week.

Luc

ltheoret

Fri, 26 Feb 2016 06:12:55 +0000

hi,

Well I had a little time so I removed R1 and R2 from my uC32 board, and now there is 100% failure rate in programming. Great, just threw a board out the window :( . Will I had the brilliant idea of using 4.7 K ohm resistors to pull the RX and TX. well it reset OK but it made things worst. No Joy.

Is there a way to lower the baud rate for programming?

Luc

ltheoret

Fri, 26 Feb 2016 06:20:48 +0000

Also tested to see if I could reset the USB - UART interface like on the UNO. turns out that when you plug in the USB, the USB 5 Volt activates the USB - UART interface, when you unplug the USB cable the pin is pulled low to resets state. So in theory everything should work great without any modifications except for the reset jumper mentioned above.

Luc

majenko

Fri, 26 Feb 2016 09:56:09 +0000

Error setting parameter 70

Yep, that's exactly the error I have been seeing too.

I look forward to a chipKIT package. Would that include hardware or just software?

It would be pic32prog, programming scripts, and kernel modules for usbserial, ftdi_sio and cdc-acm - those will allow you to talk to all chipKIT boards through the USB interface.

Well I had a little time so I removed R1 and R2 from my uC32 board, and now there is 100% failure rate in programming. Great, just threw a board out the window

Oops. You didn't really want to do that. I can replace the resistors if you want to send me the board (UK), if you think it's worth it.

Is there a way to lower the baud rate for programming?

That would mean replacing the bootloader. Doable, but you need a programmer.

Also tested to see if I could reset the USB - UART interface like on the UNO. turns out that when you plug in the USB, the USB 5 Volt activates the USB - UART interface, when you unplug the USB cable the pin is pulled low to resets state. So in theory everything should work great without any modifications except for the reset jumper mentioned above.

Yeah, with no USB cable connected the FTDI chip gets no power. With no power it shouldn't interfere at all with the UART programming. With power it will mess it up completely. As I mentioned in the blog post - do not power it through USB or it will fail - power it through the barrel jack or some other means that doesn't involve the USB. On the WF32 I used the secondary USB interface - the one that goes to the PIC32's USB pins - and set the jumpers accordingly.

I'm going to experiment with modding the Dragino to bypass the UART level shifter today, see if that helps things. It would be good to just narrow it down to just what is causing the problem, even if it's not a straightforward fix.

majenko

Fri, 26 Feb 2016 10:14:34 +0000

Will I had the brilliant idea of using 4.7 K ohm resistors to pull the RX and TX. well it reset OK but it made things worst. No Joy.

The level shifter really won't like that:

To avoid output contention issues, any pull-up or pull-down resistors used must be above 50 kΩ.

I have bypassed my level shifter and so far I haven't had a single issue with my uC32. It remains to be seen just how stable it is now though - time to try adding some more hardware and program things properly.

majenko

Fri, 26 Feb 2016 10:30:17 +0000

Ok, I cannot get this to fail at all now. So it looks like that level shifter is in fact our culprit.

In fact, get this: With the level shifter bypassed you can program from the Dragino with the USB power connected!

So most problems seem to stem from that level shifter.

ltheoret

Fri, 26 Feb 2016 15:38:20 +0000

Hi,

So the level shifter converts from 5V to 3.3V for the Linux module, and we are operating at 3.3V. Now I'm starting to understand. OK I found U2 the NTB0102GT level shifter. Now does this thing convert to 5V or to 3.3 V? It is too tiny for my skills. not touching that. but I am sure I could fine somebody here around tow that could make the changes you would suggest. I would buy more board and have them converted at the same time. All my board can operate at 3.3V

Luc

majenko

Fri, 26 Feb 2016 16:42:28 +0000

Depending on the setting of the voltage jumper it either converts 3.3V (linux) to 5V (MCU) or from 3.3V (Linux) to 3.3V (MCU). In that latter setting it is redundant.

The way I bypassed it was to run two wires from the HE module to pins 0/1 of the header. That is far far easier than doing anything with the chip itself.

Pins 33 and 34 on the module are the UART:

ltheoret

Fri, 26 Feb 2016 16:48:09 +0000

Hi Majenko,

I can do that :) . Is there anything thing that need to be done to the shift register? or just wire it and leave it?

Luc

ltheoret

Fri, 26 Feb 2016 16:58:06 +0000

So UART_RX goes to TX and UART_TX goes to RX? And I found a shop here in Edmonton that can do all sort of modifications for me. But I can tackle this one myself.

Luc

majenko

Fri, 26 Feb 2016 17:09:02 +0000

On my shield the TX and RX have already been swapped on the silk screen. So TX goes to TX on the shield, which is RX on the chipKIT, and RX to RX which is TX on the chipKIT.

ltheoret

Fri, 26 Feb 2016 17:15:22 +0000

Hi, Ah, you are write. Thanks again.

Luc

ltheoret

Fri, 26 Feb 2016 18:55:35 +0000

Hi, I have some bad news. This mod fails 100% of the time on the uC32. On the wf32 it works 100% of the time if I upload Blink. but if I upload a bridge software then try to upload blink again it fails until I reset the HU. and I only send a signal on the bridge every 5 second. Still work 100% of the time with my infiduino set to 3.3V but that uses the SPI buss not the UART.

There must be a software conflict in there to. Did not damage the UART as the database is still being updated with the WF32 and it also updates with the uC32 (not the one I tampered with).

OK. I re-programed by USB my uC32 with blink now I cam program it till I'm blue in the face (with Blin) but if I use the bridge I'm hooped. Yes it's not only my database software it's also a web based temperature demo.

Luc

majenko

Sun, 28 Feb 2016 12:19:35 +0000

I have just found that I don't need to bundle the ftdi and cdc/acm drivers, they are already there:

# opkg update
...
# opkg install kmod-usb-serial-ftdi
# opkg install kmod-usb-acm

majenko

Thu, 03 Mar 2016 15:21:55 +0000

Ok, I am gradually getting to the bottom of this now.

It's not easy. The problem is the serial console login that is used by bridge.

Disabling it and reenabling it doesn't seem to be possible. To disable it you need to:

  1. Comment out the line in /etc/inittab
  2. Killall -HUP init
  3. Kill the bridge python process
  4. Kill any ash processes running on serial

Then you can upload code reliably.

But you then cannot use bridge. At all. Uncommenting the line in /etc/inittab and HUPing init has no effect. The only way to get bridge working again is to reboot the dragino.

Sucks.

Sent from my SM-T555 using Tapatalk

ltheoret

Fri, 04 Mar 2016 04:50:37 +0000

I found on the Arduino.cc website: [url]https://www.arduino.cc/en/Tutorial/YunSerialTerminal[/url] a little peace of code that is supposed to disable the bridge from the from the Arduino side. I don't know if it disables it on the OpenWRT side.

Luc

ltheoret

Fri, 04 Mar 2016 04:58:05 +0000

Hi,

the line from the link above is

SERIAL_PORT_HARDWARE.write((uint8_t *)"\xff\0\0\x05XXXXX\x7f\xf9", 11); // send "bridge shutdown" command

sent via serial port

Luc

majenko

Fri, 04 Mar 2016 10:56:45 +0000

That would just exit the bridge server, it won't affect the fact that init is listening on the serial port and intercepting the data.

I think I am going to have to delve into the source code of busybox to see what is going on.

Sent from my SM-T555 using Tapatalk

majenko

Fri, 04 Mar 2016 16:58:29 +0000

Wow... ok, so I think I may have it!

After much use of strace and pstree and similar tools I have it nailed. I think I now know exactly what happens.

It's a comedy of errors...

Ok... first off when you disable the inittab entry and HUP init it doesn't kill the redundant processes. Those have to be done manually - and not just the python process, but the /bin/ash process as well. And they have to be killed with extreme prejudice.

Then you can use pic32prog to program the target, which is nice.

Then the next tricky part is getting things running again... Here's where the comedy begins:

When you re-enable the inittab entry and HUP init it starts the UART up at the wrong baud rate!!! Yep, it configures it for 115200 baud instead of 230400 baud (which actually seems to be 250000 baud). And no, it's not pic32prog leaving it at that rate. If you change the rate to 230400 before HUPing init it resets it back to 115200 baud. So you have to change the baud rate AFTER HUPing init.

But that's not the worst of it...

If the bridge is running on the target then init has an absolute eppy fit and /bin/ash keeps crashing and looping.

Mar 4 16:13:15 init: process '/bin/ash --login' (pid 11427) exited. Scheduling for restart.

So you need to make sure that the UART's level shifter is set to disable the UART access before HUPing init and setting the baud rate, and waiting long enough for init to have finished cloning itself before then re-enabling the UART so that the bridge can start communicating!

What a laugh, eh?

So now my run-pic32prog script looks like this:

#!/bin/sh

# First we need to disable the login:
sed -e '/ttyATH0/ s/^#*/#/' -i /etc/inittab
killall -HUP init
PYTHON_PID=`ps | grep python | grep bridge.py | awk '{print $1}'`
ASH_PID=`grep PPid: /proc/${PYTHON_PID}/status | awk '{print $2}'`

# Kill python
kill -9 ${PYTHON_PID}
# Kill ash
kill -9 ${ASH_PID}

# We need to save the current state of the UART connection
UART_SET=`cat /sys/class/gpio/gpio24/value`
# and enable the UART if needed
echo 1 &gt; /sys/class/gpio/gpio24/value

sleep 1
# Now reset the MCU and run pic32prog
reset-mcu
pic32prog -d /dev/ttyATH0 -S $*

# Disable the UART so that init can re-enable the TTY properly
echo 0 &gt; /sys/class/gpio/gpio24/value

# And finally return the login
sed -e '/ttyATH0/ s/^#*//' -i /etc/inittab
killall -HUP init
sleep 1
stty -F /dev/ttyATH0 ispeed 230400 ospeed 230400

# Put the UART setting back to what it was:
echo ${UART_SET} &gt; /sys/class/gpio/gpio24/value

I'll look at releasing a new pic32prog package with it in.

majenko

Fri, 04 Mar 2016 22:38:55 +0000

And here's the package:

http://uecide.org/pic32prog_2.0.189-1-f2988c6_ar71xx.ipk

majenko

Fri, 04 Mar 2016 22:45:11 +0000

Oh, one other thing... I have it working perfectly on a Wi-Fire. There's a small modification you need to make though - and this probably applies to other chipKIT boards as well.

You need to disconnect the SS pin on the ISP header. On the Wi-Fire there's a jumper with a hard-wired link that you need to cut. It's JP5 and the link is on the underside. An xacto or something similar (I actually used my needle tweezers) can break that track between the pads. If you should ever need to undo it it's simple enough by soldering a link between the pads of the jumper (that's what it's there for).

ltheoret

Sat, 05 Mar 2016 18:12:25 +0000

Hi, just itching to try this new fix. Well it works with my uC32. Can I remove those 2 wires that bypass the level shifters.

Luc

majenko

Sat, 05 Mar 2016 18:13:06 +0000

Absolutely. They must go, or you can't isolate the UART while rebooting the bridge process.

ltheoret

Wed, 09 Mar 2016 23:01:23 +0000

Hi,

Everything seams to be running. better than advertised (The Dragino website says it cant be done.) Thank you majenko for getting this running for me. This opens up a hole new world of home property monitoring system. It can send e-mails as alarms, you can look at the status just by logging to the onboard web server.

Luc

majenko

Wed, 09 Mar 2016 23:32:48 +0000

Brilliant! Glad it's working for you. Myself I have had no trouble uploading to my WiFire with it, and the whole system is running as my internet connection with email monitoring and traffic graphs on a TFT screen :)