(17 replies, posted in Software)

Hi, Just posting to report success. 4.7.2 working fine for me on first try.
Thanks for your work on this, Sakaki.


(3 replies, posted in Hardware)

I've put the first of the Revision 2 boards together now, and it works well.
https://www.jamiecraig.com/novena-ice40-add-on-part-5/ has the various design files.

If you want to make one yourself, the PCBs (bare) are available from dirtypcbs at http://dirtypcbs.com/store/designer/det … vena-rev-2 - I've set up that board design with zero cut for me, so you're just paying dirtypcbs standard price. If you find it's misbehaving on checkout, try changing the number of layers from four to two and then back again; it should be about $30 for the pack of 10.


(3 replies, posted in Hardware)

Hi folks,

To let people use Clifford Wolf's IceStorm package to develop FPGA projects directly on the Novena, I've build a little mezzanine board that fits between the FPGA socket on the Novena and the GPBB (or other similar boards) and provides a Lattice iCE40HX4K FPGA.

The first version of the board worked well with a single wire bridge hack and a little tricky soldering, and I've drawn up a second bug-fixed version. My first batch of these revision 2 boards is being manufactured at DirtyPCBs just now; I'll post again if there are any problems, but I expect this to work as it's just a minor improvement on the previous model.

My current plan is to write a simple bus-bridge and memory controller for the Xilinx that can be shared by any iCE40 projects, so that people can do all their FPGA development work using only the iCE40 on the Novena itself, and essentially ignoring the Xilinx part. So far I've only written enough to let us push the bitstream into the iCE40 from the Xilinx, but that's working well, and the board is perfectly capable of running a blinkenlights bistream driving the GPBB's LEDs.

If anyone's interested in this project, my latest post describing it is here:
and the previous posts at the same site.

The board design is open source (under the same Apache license as Novena) and available here: https://www.jamiecraig.com/novena/Revision%202/
with the software for programming it and the Xilinx bitstream for a basic loader here:

I won't be selling any of these (no time for production myself) but I'm more than happy for anyone who wants to build and sell them to do so. If anyone else builds one, let me know - any feedback's always appreciated.


(1 replies, posted in Firmware)

I think that looks OK for a full battery. What behaviour were you expecting, given that it's already fully charged? The terminate charge alarm just means "stop charging because the battery's already charged".


(13 replies, posted in Hardware)

dpapathanasiou wrote:

Yes, I had seen the other thread about the 3.3v fan, but I'd like to recycle the 12V one I already have, rather than get a new one.

I also read the GPBB user guide -- https://www.kosagi.com/w/index.php?titl … User_Guide -- and looked at the schematic of the pin layouts, but I'm not sure if the 12V fan would work, since it seems that max pin output from the GPBB is 3.3V, and I would need at least 5V.

Have I misunderstood the GPBB diagram?

The GPBB is perfectly capable of outputting 5v. There's a switchable output voltage - you can use the gpbb demo project and the "-hv" flag to switch it to High Voltage (i.e. 5v) mode.

You could also use the 5v pins on the front panel PCB, which can be made to automatically regulate a fan if you enable the "heirloom" flag in the EEPROM.


(2 replies, posted in Hardware)

Senoko's normal output is just the battery voltage, with the regulation done on the Novena. While Senoko's a great battery manager, I don't think it'd be terribly useful in other circumstances without adding a regulator on there too (since everything else in the world runs off 5v). That's obviously a much bigger deal than adding the header pins. Perhaps a little breakout-and-5v-regulator board that plugs into a standard senoko header would make more sense?


(6 replies, posted in Hardware)

I ended up buying one off another Novena user who'd a spare, because I couldn't find one. If you get either of those two, please let me know if they work - one of my Novenas is going in a custom case, and I could do with some extra length on the display cable.


(54 replies, posted in Hardware)

If possible, I'd like one too. (just bought my 2nd novena...)


(2 replies, posted in Hardware)

Found it. The I2C_DADDR's next state transition was slightly wrong, as it'd go into ACK_DADDR even if there was an address non-match. Since the ACK_DADDR state sets the pull-down on the I2C data line low, the result looks like an acknowledge to the iMX6. The quick and dirty fix is just to check the address when deciding on the next state from I2C_DADDR, rather than entering the ACK_DADDR state at all.

I2C_DADDR: begin // 8 bits to get the address
       I2C_nstate = ((I2C_bitcnt > 4'h7) && (SCL_cstate == SCL_FALL)) ?
        ( (I2C_daddr[7:1] == i2c_device_addr[7:1]) ? I2C_ACK_DADDR : I2C_WAITSTOP) : I2C_DADDR;

This seems to do the trick and gives me the right output both for all other addresses and for directly accessing the FPGA.

The example GPBB FPGA code has a bug where it slightly mangles the I2C bus - I think by tying the bus low when it's not being driven, although I can't see why as the IOBUF statement and constraints configuring it look right. Perhaps the level hold feature on the I/O pins on the Xilinx is stronger than the pullup on the board? I couldn't quickly see an obvious problem.

I noticed this because i2cdetect gives different answers before configuring the FPGA:

root@novena:/home/jamie/gpbb/novena-gpbb-example-master# i2cdetect -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

and after:
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 UU 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f

Bunnie's FPGA code explicitly instantiates an IOBUF to handle driving the I2C data signal, basically setting it up to either pull low or tristate at any given instant. The code for that looked OK, as did the code to switch between I2C_ACK_DADDR vs. I2C_WAITSTOP (i.e. send an acknowledge for the address vs. ignore someone else's address) so I'm not at all sure why this breaks.

Anyone already spotted and fixed this?


(8 replies, posted in Hardware)

I posted this previously on http://www.kosagi.com/forums/viewtopic.php?id=152 , but Toby electronics carry suitable cables here http://www.toby.co.uk/content/catalogue … xx-A-xx-xx which work fine. FFC5-54-A-46-8-4-54 in particular was OK for me.


(55 replies, posted in Hardware)

I ended up with mine in a similar state while playing with the calibration at one point. Recalibrating it (after checking connections were solid etc.) did fix it, but I wonder if it might be quicker for you to just reimport xobs's senoko data dump to get back to a known good state?

There was some nice work integrating an extra CPU inside an RJ45 jack, which would be feasible on Novena. Anything else, probably not - it's a little too exposed. I suppose the WLAN card is perhaps a possible route, too.


(9 replies, posted in Hardware)

gg auto 0 stopped the random senoko reboots for me - you mgiht want to try that too. I'm on the latest senoko firmware too.


(14 replies, posted in Hardware)

I've realised that my original board done in DipTrace had a pretty serious mistake, at least for my purposes - I'd used 0.1" header instead of 2mm, and the standard cables for these displays, widely available off eBay, use 2mm headers. Since I was going to have to redraw it anyway, I've redone this layout in Eagle (which does a better job of differential traces anyway) and uploaded it here:


I have literally no idea if this board works - in fact, after my last screw-up on the board layout, I imagine it's a safe bet it doesn't! - but if anyone wants a look or to use it as a basis for their own boards or whatever, go right ahead.

Caveat emptor.

PS. I rather doubt that the USB header will work well, since the impedance of the PCB will be well off what the USB spec requires for USB 2.0 - it's tricky to get this right on 1.6mm 2-layer board when you have the signal coming from tiny narrow connectors too. I'm sure someone will be able to do a better job of this than me, but it's a start.


(14 replies, posted in Hardware)

projectgus wrote:

Neat! Any chance you posted it online as well?

Not yet. I'll consider it once I actually get the boards back and see if they work worth a damn. I'll probably redo the layout a bit before I post anywhere else, simply because I think my layout is a bit crap - I was in a bit of a hurry. Once I'm a little less busy I'll do a better quality layout and tidy up the silk-screen better etc. so it's something I'm happy having my name associated with.

projectgus wrote:

I'm also interested in maybe doing a group order for the custom FPC. itead and some of the other cheap PCB services will do it, but it's still reasonably expensive. I think when I last looked it was about $100US for qty 10. Let me know if you're interested too, and I'll start another thread about ordering some.

I've just found that toby.co.uk - http://www.toby.co.uk/content/catalogue … xx-A-xx-xx - carry the 54-pin FFC cable, albeit in odd lengths.


(14 replies, posted in Hardware)

I've actually laid out a basic board for this and passed the files on to Sourcerer. I've also ordered myself up a few from dirtypcbs, and the connectors from RS - I may have a few spare, if it actually works. However, I haven't found a source of the 54-pin FPC cable, nor the novena-specific fancier version bunnie produced. Anyone have any suggestions where I could obtain such a thing? (I'm MadHacker on IRC, BTW)


(69 replies, posted in Hardware)

GregRob wrote:

After poking around a bit more, and trying:
  gg auto 0
  chg set 1000 11100
  gg chg +

I still haven't gotten the charger to run.

I got precisely the same effect until I shorted out the appropriate temperature sensing pins, oddly - despite setting "gg tempsource greater" already. Sticking the jumper across the TS pins fixed it and mine has now gone into charge, happily.


(69 replies, posted in Hardware)

pelrun wrote:

I've finished putting verification code into the flashing tool; I don't think there's anything else I can do to make it safer to run than it is now. So if someone with a locked chip wants to give it a go?


Thank-you! This worked fine for me. Much appreciated.


(69 replies, posted in Hardware)

OK, I'm back at my own place and ready to work on this again.
I get the following with four (real, ish) cells wired up, the TX pins on U302 shorted appropriately, and in general things wired up "properly" so the chip should be happy:-

ch> stats
Manufacturer:       Texas Inst.
Part name:          bq20z95
Firmware version:   0x5009
Charge FET:         off
Discharge FET:      off
State:              normal discharge
Time until full:    65535 minutes
Time until empty:   65535 minutes
Chemistry:          LION
Serial number:      0x0001
Charge:             69%
Max capacity:       2866 mAh
Design capacity:    4400 mAh
Temperature:        25.24455 C
Voltage:            15482 mV
Current:            -4 mA
Average current:    -1 mA
Target voltage:     0 mV
Target current:     0 mA
Number of cells:    4 cells
Cell 1 voltage:     3819 mV
Cell 2 voltage:     3875 mV
Cell 3 voltage:     3993 mV
Cell 4 voltage:     3796 mV
Charge status:      0x0
    Charging allowed?   yes
    Can suspend?        no
    Can precharge?      no
    Can maintenance?    no
    Temperature limit?  no
    Temperature limit?  no
    Can fastcharge?     no
    Pulse charging?     no
    Pulse disable CHG?  no
    Cell balancing?     no
    Precharge timeout?  no
    Fastcharge timeout? no
    Overcharge OV?      no
    Overcharge OC?      no
    Overcharge?         no
    Battery empty?      no
Charge state:
    Battery initialized
    Battery discharging/relaxing
No errors detected
No safety alerts
No safety status messages

No amount of "gg cells 3", "gg capacity 3 5000" will make it write to the chip well enough to update the output of the stats command. Also, setting the charger directly doesn't seem to work very well either:-

ch> chg
Charger information:
        Charge thread:    running
        Manufacturer ID:  0x0040
        Device ID:        0x0007
        Current:          0 mA
        Voltage:          0 mV
        Input:            3840 mA
ch> chg set 1000 16000 4000
Setting charger: 1000mA @ 16000mV (input: 4000mA)... Ok
ch> chg
Charger information:
        Charge thread:    running
        Manufacturer ID:  0x0040
        Device ID:        0x0007
        Current:          896 mA
        Voltage:          16000 mV
        Input:            3840 mA

---I wait 10 seconds here---

ch> chg
Charger information:
        Charge thread:    running
        Manufacturer ID:  0x0040
        Device ID:        0x0007
        Current:          0 mA
        Voltage:          0 mV
        Input:            3840 mA

At the end of the process the stats output is the same as at the start. The only thing I see of note is the stuff under "Alarms" in the gg status. I can't seem to find a way to reset those, even though the battery status is otherwise fine. gg pfreset and reboot doesn't help either. Forcing the charger output on the gg on (with gg chg +) doesn't seem to affect anything either.

Any ideas?


(11 replies, posted in Hardware)

roheve wrote:

Can I solder wires to them (probably, but I don't know if it is safe), or do I need a battery holder?

It's possible, but really not recommended, since you cook the cell somewhat doing it. I've managed OK in the past doing it with a water torch (oxygen-hydrogen torch, commonly used for making jewellery) which gives you a huge amount heat in a tiny area, much like the weld does, but I wouldn't combine lithium cells and a normal soldering iron - you're just asking for trouble. Stick to holders or spot-welding. smile


(69 replies, posted in Hardware)

It appears I lied - it's happy only in the sense that it'll talk to me willingly, but it does the same as everyone else's and won't save the gg cells 3 command.

I actually tried DIYing up and connecting a four-cell battery (having removed R305 first!) and managed to get the stats command to report no safety alarms. However, even in this state, and with no "bad" numbers or statuses showing, it never seems to write the number of cells back (although the command completes successfully). I get much the same results for every other command to the gas gauge - the command completes fine but doesn't appear to write to the data flash of the gas-gauge chip.

I can't quite work out which condition is causing the data flash to lock out, unfortunately, and I'm not at home for the next two weeks, so I'm severely constrained for equipment to poke at it further.


(69 replies, posted in Hardware)

Oh, I'm an idiot. There's no battery attached so no power to the GG chip. Tap the prime button to give it a little juice and it's happy. smile


(69 replies, posted in Hardware)

Mine is behaving broadly similarly. Trying a few times to set the capacity, for example, gives:
ch> gg capacity 3 5000
Setting capacity... Unable to set capacity: 0xFFFFFFFE
ch> gg capacity 3 5000
Setting capacity... Set capacity of 3 cells to 5000 mAh
ch> gg capacity 3 5000
Setting capacity... Set capacity of 3 cells to 5000 mAh
ch> gg capacity 3 5000
Setting capacity... Unable to set capacity: 0xFFFFFFFE
ch> gg capacity 3 5000
Setting capacity... Unable to set capacity: 0xFFFFFFFE
ch> gg capacity 3 5000
Setting capacity... Set capacity of 3 cells to 5000 mAh

similarly, stats gives:
Manufacturer:       error 0xFE000000
Part name:          error 0xFE000000
Firmware version:   error 0xFE000000
State:              error 0xFE000000
Time until full:    error 0xFE000000
Time until empty:   error 0xFE000000
Chemistry:          error 0xFE000000
Serial number:      error 0xFE000000
Charge:             error 0xFE000000
Max capacity:       error 0xFE000000
Design capacity:    error 0xFE000000
Temperature:        2184.5 C
Voltage:            error 0xFE000000
Current:            error 0xFE000000
Average current:    error 0xFE000000
Target voltage:     error 0xFE000000
Target current:     error 0xFE000000
Number of cells:    error 0x1000000
Cell 1 voltage:     error 0xFE000000
Cell 2 voltage:     error 0xFE000000
Cell 3 voltage:     error 0xFE000000
Cell 4 voltage:     error 0xFE000000
Charge status:      0x5555
    Charging allowed?   yes
    Can suspend?        suspended
    Can precharge?      no
    Can maintenance?    yes
    Temperature limit?  no
    Temperature limit?  yes
    Can fastcharge?     no
    Pulse charging?     yes
    Pulse disable CHG?  no
    Cell balancing?     in-progress
    Precharge timeout?  no
    Fastcharge timeout? yes
    Overcharge OV?      no
    Overcharge OC?      yes
    Overcharge?         no
    Battery empty?      yes
Charge state:
    Battery discharging/relaxing
    Battery fully discharged
Unable to read safety alerts
Unable to read safety status


(208 replies, posted in Hardware)

That's mine arrived and flashed - mostly works, I think. I've got some problems, but I'm sure they're fixable - there's an existing thread about flashing it so further discussion on that will be over there. Thanks again, mclien!