I dislike hardware flow control

I can’t ever seem to get the flow control lines right.   The current prototype only works with flow control disabled.

The N2 Platform docs says that the Serial3 signals are”ModemNotCTS” and “ModemNotRTS”.  The WiReach docs also use inverted signals “nCTS” and “nRTS”.  So I connected them up to each other thinking that they’re all using the same signaling logic.

But I was wrong, and I think the n2 docs are too.  It seems that the Newton’s CTS line is not inverted.  This can be verified with a  loopback.  When RX-TX are connected and RTS-CTS are connected, you will not get an echo when hardware flow control is enabled.

Similarly, if you connect CTS to GND, you won’t get an echo.  If you connect CTS to 3v, you get the echo.

So this tells me that CTS is not inverted.  Per this site:

RTS and CTS are normally held high (TTL 1).  When high, no request (RTS) has been made, and no permission (CTS) has been granted.  When the PC is ready to send data, it brings TTL RTS low.  The MCU sees this.  When the MCU is ready to receive data, it brings TTL CTS low.  The PC sends data as long as TTL CTS is low, and stops when the MCU takes TTL CTS high.

The opposite seems to be happening no the Serial3 signal.

So what next? Well the board works fine without hardware flow control… but I’m going to try and “dead bug” a 1 gate inverter onto the board on the RTS line coming from the WiReach.  It won’t be pretty, but it should work.

Serial Channel 2

The Newton’s internal serial slot exposes 3 serial channels.   Serial 1 and Serial 3 are the most interesting, as they have a full set of signals and are selectable by the selection signals.

I was searching for a way to control SerPortSel3 within software.  When you open the serial port on the Newton, it sets SerPortSel3 LOW.  I had hoped there was a parameter you could pass to the endpoint that would keep SerPortSel3 high.  (See earlier posts)
I was searching the DDK headers and I found this (HALOptions.h)
#define kHWLocExternalSerial ‘extr’
#define kHWLocBuiltInIR ‘infr’
#define kHWLocBuiltInModem ‘mdem’
#define kHWLocPCMCIASlot1 ‘slt1’
#define kHWLocPCMCIASlot2 ‘slt2’
#define kHWLocPCMCIAAnySlot ‘slot’
#define kHWLocBuiltInExtra ‘tblt’
kHWLocBuiltInExtra seemed promising.  I haven’t seen it mentioned in any of the other docs.  So I whipped up a little package to enable it as a valid modem location:
InstallScript := func(partFrame,removeFrame)
   begin
AddArraySlot(GetGlobals().ModemLocations, {title: “Modem”, id:”mdem”});
AddArraySlot(GetGlobals().ModemLocations, {title: “Extra”, id:”tblt”});
   end;
I had hoped that ‘tblt’ would open Serial3 and set SerPortSel high.  This is not the case.  It turns out that kHWLocBuiltInExtra is actually Serial Channel 2.
The n2 platform documents say that SerialChannel2 is a “low speed channel for printer support”.  I’ve also seen references that Serial2 is for keyboard.  Since Serial2 is not exposed on the external port, I don’t think that it is used for the keyboard.
In all, kHWLocBuiltInExtra is one more piece of the internal serial slot puzzle.

It Works! (Sorta…)

It works! (Sorta) I finally got all the parts together to assemble the project. I started by populating the 3.3v regualtor section of the board, just to make sure it works. It did, a nice stable 3.29v.

I then proceeded to blow up the regulator somehow. I was trying to load it with a few ohms of load to simulate a 300mA draw… but that shouldn’t destroy the thing. Maybe I connected something incorrectly or zapped it with static. Luckly, I had enough parts to try again. Again I populated the 3.3v regulator first, and checked the output. Again, a nice output voltage. This time I threw caution to the wind and just populated the rest of the board.

At first I thought the thing was not working. But then I tried disabling flow control, and moudle responded.

This means a few things:

  •  Power regulation seems to work as expected
  • The auto reset (which holds the module in reset until power-good) seems to work. 
  • The buffer IC is forwarding the RX and TX lines between the Newton and the module properly. 
  • My track record for screwing up hardware flow control may be unbroken. (Sadly)

Now there are a few things going on here, so maybe the hardware control isn’t broken. 

First, when PT-100 connects, it turns off the SerPortSel3 signal. This powers down the module. PT-100 then reports a Buffer Under-run… I can then manually toggle SerPortSel3 and communicate with the module. I am wondering if the fact that the module is powered off during the process of opening the serial port does something to hardware flow control. Maybe it gets things in an inconsistent state. I am not sure.

I haven’t tried using NIE yet, but I was able to connect to my WiFi network (WPA2) and ping my router using the AT+i command set.

Now if only I can figure out why hardware flow control doesn’t work!  If someone wants to check my work, the relevant part of the circuit can be found below:

WiFi Update

Some updates on the project:

  1. I was unhappy with the linear regulator’s heat performance, so I changed to a switching module.  This increased the number of passive components a bit.  I found a nice module from TI that has an integrated inductor, so the whole thing still fits nicely.  The PCB layout is tricky for switching regulators, but I did my best to follow the guidelines in the data sheet, so I’m hopeful it will work as expected.

    Rather than making a separate breakout board to prototype the regulator, I just went ahead and ordered the PCBs for the whole project.  I’ll reflow the regulator components first and test the circuit out before reflowing again to add the WiReach and additional components.

  2. Mathias suggested a buffer to translate between 3.3v and 5v signals, but this is all 3.3v logic.  I did add a buffer for another reason– the fact that the module is powered separately from the Newton means that the Newton can be pushing 3.3v logic signals when the module is powered off.  I checked with ConnectOne and the module is tolerant to this, but it wastes power and possibly causes problems with an inconsistent state on power-up.  By using a buffer, the logic signals are kept at the same voltage level as the module itself.  I chose a buffer that has “power off protection on inputs and outputs” which means the buffer can be at Vcc=0 and still tolerate signals coming from the Newton.1
  3. I have an idea for the reset circuit.  The power regulator has a “Power Good” output that holds to ground until the power regulation hits the target voltage.   The idea is to tie this to the WiReach module’s reset pin.  This should hold the module in reset until the power regulator is fully online.  This only costs one extra pull-up resistor.

    In case this strategy doesn’t work, I’ve got an alternate setup where the Newton’s extra GPIO can trigger the reset.  The GPIO is looped through the buffer, again to keep the logic at the same voltage as the WiReach supply.  A solder jumper selects which reset circuit you wish to use.  The WiReach reset pin is an open-drain, and can be pulled low by the module.  I added a 200 ohm resistor inline to limit the current should the Newton be outputting a 3.3v signal while the module is pulling down its own reset signal.

  4. Switched the test pads to just pads rather than thru-holes.  Moved them near the edge of the board so I can clip on with alligator clips to test.  Exposed the reset and MSEL signals as test pads on the back of the board as well.  These can be used to reset the module into rescue mode if necessary.
  5. Some of the routing is a little odd but I tried to keep the jumpers on the bottom layer as short as possible.  This resulted in few extra vias.  I wanted to keep the ground plane as intact as possible.
  6. I’m still paranoid about the hole locations and the physical design fitting properly, so I 3D printed another mockup to test the fit.  Seems to work well.  Hole placement is still iffy.  I’d love to know the real measurements.  Each time I tweak it a little, but never seem to be happy, so I’m finally just going with it.

So the board is off at ITEAD Studio being built, assuming it passes their error checks. update: it passed error checks and is being manufactured I also ordered two solder stencils from OSHStencils.  I also built a reflow toaster out of an old toaster oven I got for free from a garage sale.  All that’s left is to get some solder paste.  I also want to build a little pick and place jig to help place the small components.

Hopefully this will all work in the end… and then there’s still the antenna to figure out.
________

  1. The data sheet for the On Semi MC74VHCT50A is vague on exactly what “Power Down Protection Provided on Inputs and Outputs” actually means.  I did a little testing on the bench, and found that when Vcc=0 the inputs and outputs seem to work like they are Hi-Z. (I’m not sure how to verify that they are definitively Hi-Z, but I can’t measure any current flowing in or out when Vcc=0) It expect it to work for this application. ?

SSL: An Exercise for the Reader

As a diversion, I tried to compiling an SSL library for the Newton.  I settled on CyaSSL, because it is designed for constrained devices.  For example, you can define macros that conditionally compile for devices that have NO_FILESYSTEM or NO_DEV_RANDOM.  That sounds a lot like the Newton.

Building

I got surprisingly far in compiling the library.  First you need to edit settings.h and add a section defining the compilation for the Newton, then pass this definition using “-D NEWTON” to the compiler:

    #ifdef NEWTON
        #define USER_MATH_LIB
        #define BIG_ENDIAN_ORDER
        #define SINGLE_THREADED
        #define NO_DEV_RANDOM
        #define NO_FILESYSTEM
        #define NO_STDIO_FILESYSTEM
        #define CYASSL_USER_IO
        #define NO_WRITEV
        #define SIZEOF_LONG        4
        #define SIZEOF_LONG_LONG   4
    #endif

One issue is that the Newton doesn’t seem to support an 8-byte integer data type.  There is one configuration in settings.h where they #undef SIZE_OF_LONG_LONG. (I assume this is if you don’t have a long long datatype) When I try this, it throws an #error, so I set both SIZEOF_LONG and SIZEOF_LONG_LONG to 4 and everything seems to compile.  (Note: There is a Int64 datatype in the C++ headers, but its just a struct with two longs.)

Next you need to define a GenerateSeed() function in random.c.  I just passed rand() from the CLibrary back.  The Newton doesn’t have a /dev/random or a good source of entropy that I know of.  I just wanted to get things to compile.  Randomness is important for encryption. In practice, a better source of entropy might be needed.

int GenerateSeed(OS_Seed* os, byte* output, word32 sz)
{
    return rand();
}

Next you’ll find a odd casting error in internal.c in GetHandShakeHeader:

File “:src:internal.c”; Line 3136 # Error: <function argument>: implicit cast of pointer loses ‘const’ qualifier

The c24to32 is an inline function, and the const qualifier was getting lost for a reason I don’t understand.  I manually inlined the function in the one spot where there was a problem.

In internal.h there is a buffer structure that throws the following error:

File “:cyassl:internal.h”; Line 930 # Error: ‘buffer::buffer’ must be a function
File “:cyassl:internal.h”; Line 931 # Fatal error: Failure of internal consistency check
odd ctor type in struct ‘buffer’

The issue appears to be that the compiler does not like the struct being named the same as one of the members.  I add an underscore to the struct name.  This doesn’t really affect anything else because its in a typedef and future code uses the type:

typedef struct buffer_ {
    word32 length;
    byte*  buffer;
} buffer;

Next, you need to modify dh.c to use <fp.h> for the pow() and log() functions rather than math.h (which doesn’t exist in the Newton C++ Toolkit)   There is a place in dh.c for you to place this code, and a macro (USER_MATH_LIB) in the settings.h file that conditionally compiles it in.

#ifndef USER_MATH_LIB
    #include <math.h>
    #define XPOW(x,y) pow((x),(y))
    #define XLOG(x)   log((x))
#else
    #include <fp.h>
    #define XPOW(x,y) pow((x),(y))
    #define XLOG(x)   log((x))
#endif

Finally, you need to compile the c files.  I snagged a list of the c files out of the make file (am__src_libcyassl_la_SOURCES_DIST) and made my own little makefile to call ARMCpp using the mpw tool. (mosrun would work too, but I already had an mpw makefile from another project.)  I took Demos.cp and Demos.exp from the NCT example code and modified them to call a few of the CyaSSL initialization functions.  (Otherwise the linker won’t link in any of the CyaSSL stuff, since its not used anywhere) I tried to link with ARMLink…

…And… it links!  I was surprised, because I expected there to be some random assembly file or something with symbols that I missed.  The .sym file is around 386kB.  Seems like a reasonable size.

Things go wrong: Static globals

The next step in using C/C++ code in a Newton app is to make the .ntkc package using the AIFtoNTK tool… and this is where things go wrong:

### AIFtoNTK – error –  the file ‘CyaSSL.sym’ has a R/W global variables which is NOT supported in Newton packages.
#    You can use ‘const’ global variables & ‘*const’ pointers.

Per the “NCT Programmer’s Reference”:

    Any global data that you reference in your C++ functions must be read-only data. You must reference this data with a constant pointer to constant data […]
 
    You sometimes need to allocate memory for use in your C++ code that is like global data. Since you cannot use non-constant global data in your C++ code, you need to utilize a coordinated effort between your NewtonScript and C++ code to achieve this.

CyaSSL is pretty light on the static globals variables, but there are some sprinkled throughout.  Here are some that I found using a simple grep:

  •     sniffer.c has a bunch, but I think this can be excluded
  •     ssl.c has a mutex and a global random number generator object, and some related counters
  •     io.c has errno as a global variable
  •     des3.c has a few buffers and bytes, and a mutex
  •     ecc.c has a cache of some sort.
  •     memory.c uses globals to hold the malloc, free, and realloc functions.  These can be changed to static globals and #ifndef out the inside of CyaSSL_SetAllocators, since it won’t be necessary.
  •     there may be others that I didn’t find.

Not all of these get linked in, they all might not not need to be fixed.  This is more retrofitting then I care to tackle.  I’m guessing that we’d need to MakeBinary() on the NewtonScript side and access these binaries using the NCT functions for accessing NewtonScript objects.

Newton Globals

I put together a little stub function that simulates a global variable by storing a pointer in a NewtonScript frame and passing that information back and forth between the C++ code.  The prototype looks something like this:

void* NewtonGlobal(RefArg sym, long size);

You give the global a unique name and pass it as a symbol.  If the symbol does not exist, a memory block of the given size is created, the pointer is stored in the NewtonScript frame and returned.  If it does exist already, then the pointer is retrieved and returned.
With this a very ugly preprocessor macro can be used to remove the static global:

static SessionRow SessionCache[SESSION_ROWS];

becomes

#define SessionCache ((SessionRow*)NewtonGlobal(SYM(SessionCache),sizeof(SessionRow)*SESSION_ROWS))

Ugly, but it should work.  I am able to compile, link, and package the CyaSSL library as a .ntkc file.  My “test” file tries and calls a few of the CyaSSL function so that the linker will find them in the dependency tree… but in practice there may be more static globals to tackle.

Other considerations

Besides the globals issue, there needs to be some glue code that allows NewtonScript to call CyaSSL and pass data back and forth.  NIE doesn’t support the traditional concept of a “socket”.  On the plus side, CyaSSL has an abstracted I/O architecture.  You can define functions for input and output instead of the default socket implementation.

Also, its quite likely that there are many more compiling & linking issues hidden.  When the library is used in practice, there will be more parts of the library in the dependency tree, and we may find new errors or static globals.

An Exercise for the Reader

I think that CyaSSL is a good choice for the Newton.  If you’re interested in learning more about CyaSSL, here are some good starting points:

I don’t know how many places these global variables might pop up in the CyaSSL code.  Also I’m not an expert on NewtonScript/NIE Endpoints and what well designed “glue” might look like.  Could it be done? Probably.  It is more work than I want to tackle with this little digression.

While I may dabble with this a little more, I don’t think I’ll see it through to completion.  I invite someone else to pick up the ball run with it. You can find me on NewtonTalk if you have any questions about what I have tried up till this point.  I’m happy to help out, but given the weird encryption export laws in the USA, I don’t want to post any code directly.

Initial Design of Internal WiReach WiFi Board

I have been triangulating on a final PCB design for an internal WiReach card.  I am not an EE, so the design is hobbiest-grade at best.  Here is the thinking behind some of what you see in the picture above:

1.  Board size is less than 5cm x 5cm in order to print it at iTead Studio at a reasonable cost.  10 of them on 0.8mm board should be around $15.

2.  Hole locations were determined based on trial and error.  I have a 3D printer, so I printed 6 or so iterations of the board and then checked the fit and hole locations.  If someone has better dimensions for the location of the mounting points, please let me know.

Screw size seems to be #1-72.  Length is 3/8″.  Flat head.  Phillips.  Shannon from NewtonTalk was selling an original SER-001 on eBay.  I have a SER-001 too, but I’ve lost the screws.  Shannon was nice enough to measure the screws for me, and confirm that the head diameter is ~0.136.  This seems consistant with McMaster part number 91771A168, but I would love to find an flat undercut version of this screw.  Unfortunately, it doesn’t seem to be available in this length.  At least now I can get some screws for both my SER-001 and this project!

Eagle PCB tends to want to route things across the mounting holes as plated vias.  Since these holes will need to be countersunk, I didn’t want to rely on these holes.  Drilling the countersink will break the plated thru hole.  Hence a couple of extra vias are nearby to make sure there isn’t an issue.

3.  I trimed down one side of the board to give a little more clearance for the microphone and power switch wires.  This isn’t strictly necessary, since the wires have their own recess in the stylus assembly.  Since I don’t know how/where I’m going to route the antenna yet, but I figured a little extra room wouldn’t hurt.

4.  I added a 500mA PTC Fuse, since the battery leads are unfused.  While there’s not going to be any external connector to short out, I figured this was a safe play.

5.  I chose the Texas Instruments REG103 regulator, mainly because I was able to get a handful cheaply on eBay and it has a shutdown input.  Also its pretty low profile and won’t interfere with mainboard components. The shutdown signal will will be driven by SerPortSel3.  SerPortSel3 is normally low, keeping the regulator off.  When toggled high in software the regulator will come online and power the WiReach.  This way, the module will only be powered when in use.  This regulator can handle 500mA.  At peak, the WiReach should only use 60% of this amount.

6.  The large copper planes on the top side are for battery power, ground and 3.3v.  The intent to help cool the regulator.  I’m not sure what the thermal characteristics will be in practice.  Power and ground traces are 30 mils wide, which is more than double what the online trace width calulators say you need for 500mA.

7.  Headers for debugging give access to the power lines on one side and the communication lines on the other.  In practice, I intend to tape over the pads so that there’s no possibility of a short.  (I may go a little crazy with Kapton tape just to make sure the board doens’t flex into something and cause a short to the mainboard.)

8.  The ground plane on the backside is only broken by a few signal jumpers where routing couldn’t be done on the top side.

My next steps are to verify the connections one more time to make sure everything is correct, and then send the board off to be made.  In the interem, I’m going to build a reflow toaster oven.

WiReach Module Connection Test

All of this work on the internal serial slot is in support of my WiFi module project.  The goal is to build an internal interface to a ConnectOne WiReach module.  I like this module for a few reasons:

  1. It supports modern wireless networking, such as WPA2.  There isn’t any native way for the Newton to connect to a modern WiFi network, and likely there never will be.
  2. It supports a PPP server.  This means that the module can appear to Newton Internet Enabler (NIE) as a PPP dialup server.  In effect, you can “dial up” to a wifi network.
  3. It supports an AT command set for configuration– so you can send a few commands from PT-100 or using the script utility in NIE to configure the module.  

I’ve done some testing today and found that it works really well.  A few caveats:
  • The Newton’s internal 3.3v regulator is not sufficient to run the module.  This was expected, but it does mean that any design will have to have a 3.3v regulator that runs off of the battery supply lines.  Luckily the internal serial slot does provide access directly to the battery.
  • Hardware flow control seems to work.  I have a history of messing up the pinout, so I’l probably have a solder jumper that you can cut if you want to disable hardware flow control.
  • There’s a giant capacitor right where I would want the module to sit.  I think that that there is enough clearance in the area, but I’m starting to be concerned about how this will all fit.
My current thinking is to use the SerPortSel3 line to control the 3.3v regulator shutdown.  Serial3 is just as fast as Serial0 (even though the specs say that Ser3 is slower, this doesn’t appear to be the case,  it works fine at 119200)  I wouldn’t want the module running all the time, drawing power.  SerPortSel3 would work to turn on and off power to the module.  Since no one ever connects anything to Serial3 externally, I am thinking that I might skip a tri-state bus buffer. 

Posted to GitHub: Internal Serial Enabler

I have posted the source to “Internal Serial Enabler” – a small newton app that allows you to view and control a few of the signals of the internal serial slot on the MessagePad 2×00:

  • gpSerPortSel – the serial port 0 selection signal.  When high, the internal serial driver is disabled, leaving Serial0 available for the internal slot.
  • PortSelect – the serial port 3.  When high, Serial3 is available for the internal slot.  When low, Serial3 is dedicated for the external interconnect port.
  • General Purpose I/O – Pin 26 can either be an input or output signal.  Using the app, you can select whether you want the app to be an input or an output.  If you select ‘output’, you can control the signal.
The application polls all three I/O signals and updates the user interface state every 1/2 second.  This will allow you to see when other applications or NewtonOS makes changes.  The gpSerPortSel pin does toggle on and off, enabling/disabling the driver.  This is likely for power saving.
Once again, I can’t credit Eckhart Köppen enough for posting the source to Newton-Blunt-Support.  It is how I learned to call arbitrary ROM functions.
This application is intended for developers working on hardware for the internal serial slot.  If you are not such a person, do not install this application.   It should be harmless for a Newton with an empty internal serial slot.  Even still, you are toggling hardware signals with undocumented ROM functions… there is the potential to do hardware damage.
You can find the source and a pre-built package on GitHub here: https://github.com/jake-b/Newton-Internal-Serial-Enabler  I have released it under GPL v2.0 and as always, use it at your own risk!

General Purpose I/O Line

Pin 26 on the internal serial slot is listed as a “General Purpose I/O”.  The Internal Serial Slot Developers Guide says that this pin can be configured as either an input or output.

The question is, how is this pin connected?  What GPIO or DIO pin is it connected to?

Well the answer seems to be GPIO #9.  Again a little tweaking of Eckhart’s code lets you call the relevant functions and toggle the pin.

Also, you can configure the pin as an input, and things work as expected.  From a hardware design perspective, however, this pin will likely be an output (pulled to ground) until your software configures it as an input… so your hardware should be tolerant of the pin as both an input and an output.

One interesting note, is the N2 platform overview (p 1-29) document lists this GPIO as “Serial NOT CP Enable”.   This doesn’t seem accurate.   Also DIO #2 is listed as “Available for Configuration to the Slot”.  DIO #2 is the output we use to configure SerPortSel3.  Perhaps there is a documentation error here and these signals are reversed.  Maybe these were reversed in the final hardware design and the documents were never updated.  Its a mystery.

I also updated my little app to support the GPIO pin for both input and output.  I’ll post the code to Github soon.  Really this is intended for developer use, so it is not recommended that the average user install this application on their Newton.

Manually controlling the SerPortSel Pins

Eckhart Köppen, author of the Blunt, the Newton bluetooth stack, has posted code on GitHub for manually controlling the SerPortSel3 signal.  His code manually controls the proper DIO pins using functions in the Newton ROM.

While this method works great for Serial3, I wanted to also control Serial0.  So I started looking at the ROM.  I found two functions in the ROM explicitly for controlling these signals:

0x0026d050 SerialPort0LineDriverConfig__16TVoyagerPlatformFUcT1
0x0026d094 SerialPort3LineDriverConfig__16TVoyagerPlatformFUcT1

I took a look at the assembly for these functions and found them to be pretty simple.  The first parameter seems to be a boolean and the second a bitfield.  I’m not exactly sure what the second parameter does, but it changes the behavior of the function when it finds the 0x20 bit set.

From what I can tell, for the Port3 function, you can leave the second parameter as 0x0 and the first parameter is a bool that controls the signal.  For the Port0 function, the first parameter the logical inverse of the signal you want, and the second parameter should be 0x20.

  • SerialPort0LineDriverConfig(0,0) // results in Port0Sel High 
  • SerialPort0LineDriverConfig(1,0) // results in Port0Sel High 
  • SerialPort0LineDriverConfig(0,0×20) // results Port0Sel High 
  • SerialPort0LineDriverConfig(1,0×20) // results Port0Sel Low 
  • SerialPort3LineDriverConfig(0,0) // results in  Port3Sel Low 
  • SerialPort3LineDriverConfig(1,0) // results in Port3Sel High 
  • SerialPort3LineDriverConfig(0,0×20) // results in Port3Sel Low 
  • SerialPort3LineDriverConfig(1,0×20) // results in Port3Sel Low

Eckhart’s code is an awesome blueprint for calling arbitrary memory locations, so it was easy to modify it to call these two functions.  Putting it all together, I whipped up this little Newton application:

Still a little more work to do, but good enough for development and testing.

Incidentally, when called with the correct parameters, the assembly behind SerialPort3LineDriverConfig is virtually identical to Eckhart’s code.  The SerialPort0LineDriverConfig is very similar but uses as GPIO instead of DIO.