Great work Mark. -Fabien.

Nice work Matt.
The good thing is that users will have multiple options to choose from... I guess...

@NXTwoThou We're working on solving many of the issues that you brought up. Please stay tuned. Cheers, -Fabien.

Chris,

2.5.0 is listed as the supported flashing tool on the STM32F051

While the tool is capable of flashing an STM32F0x chip, it is missing several STM32F0 device map files.
I created a map file for the STM32F051 Medium Density with 64K of flash (see the attachment) and tested it against an STM32F051 Discovery board.


-Fabien.

Hi Chris,

About this:

3. Reflashing using the USART pins (and ST's Flash Demo Loader application...or the reflash tool provided on Netduino).

1. Are you sure about the ST Flash Loader application? Version 2.5.0 does not support flashing the STM32F0x series. Can you please share a link to the updated tool?
2. About the 'reflash tool provided on Netduino': can you please provide a link to the RTM version of the tool? The last version I tested did not work properly with the Display Module.

Thanks,
-Fabien.

Thanks for the update Chris. You made my day Also, since we're on the subject of new modules: [nwazet has a new undisclosed module for release in early August ;-) So, definitely a busy summer... Cheers, -Fabien.

Chris,

 

"[color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;font-size:14px;]I'm guessing that 10.5 mbps was too fast for the module. That's a lot of data for a 48MHz microcontroller to handle that's also updating a display...so 5.25 mbps seems totally reasonable"[/color]

 

[color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;font-size:14px;]You guessed wrong.[/color]

 

• [color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;font-size:14px;]The Touch Display module runs on a [/color]STM32F205RET6 [color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;font-size:14px;]at 120 Mhz.[/color]
• [color=rgb(40,40,40);font-family:helvetica, arial, sans-serif;font-size:14px;]The DAQ module runs on a [/color]STM32F051R8T6 at 48 MHz.

In both cases, the processing work that they perform is independent of the SPI communication throughput because it's buffered and asynchronous. A simple examination of our SPI over DMA source code would have avoid a misleading statement.

 

For the record, throughput has never been an issue with our modules until GoBus introduced SPI handling changes. 

Hi Chris,

Hi Fabien,

Thank you for digging into this further. Glad that a simple code change seems to get users back up and running.

If I remember correctly, the old firmware had a bug where it would send SPI traffic at either half or double the requested speed (depending on how you look at it). This was fixed in 4.2.1 via a bugfix check-in from the STM32 core. It may have been an issue with only one of the two buses (since they run on different peripheral clocks which could run at different speeds).

Can you check the actual throughput speed on your logic analyzer (both with the old firmware and with the new firmware) and verify that it is now correct? If the bugfix shifted the speed the wrong way, then we'll want to fix that. If it shifted it the right way, then the speed was incorrect before and I would recommend updating your code.

With GoBus 1.5, these sorts of issues go away. The I/O frames are taken care of by the framework...so you can focus on your application. This also enables your gear to be used on different transports.

One other thing: the STM32 chips run SPI at an even divisor. With the 168MHz MCU and internal 84MHz peripheral clock, that means that the SPI bus can run at 21MHz or 10.5MHz. So selecting 25MHz will generate a 21MHz SPI clock and selecting 16MHz will generate a 10.5MHz SPI clock.

Chris

I'm very familiar with the complexity of the ARM Cortex clock tree and I know how easy it is to mis-configure a peripheral's clock divider / pre-scaler.

Per your request, I have attached two Logic captures running on firmware 4.2.1, with the SPI bus (socket 5) configured at 10Mhz and 5Mhz respectively. As you can see, the SPI clock frequency is half of what it should be, which explains the regression.

This did not happen with firmware 4.2.0 where the actual SPI clock frequency matched the frequency requested by the application (give or take the rounding delta introduced by the configuration of the peripheral's divider / pre-scaler).

You should be able to reproduce my findings and do regression-testing on your own ARM-based modules (SD, Ethernet and ShieldBase), assuming that they are configured to use the SPI buses on the Go at frequencies above 16MHz.

Regarding GoBus: adaptive bus speed negotiation will be useful when dealing with runtime bandwidth issues. However this 4.2.1 firmware bug would impact GoBus just the same because it affects the configuration of the ARM Cortex clock tree for the SPI peripheral, systematically cutting the maximum frequency in half.

I certainly look forward to your native reference implementation of GoBus 1.x+.

While we wait for a firmware revision addressing this SPI frequency regression, we'll document the mitigation on our site.

-Fabien.

I just completed the investigation of the issue and here's what I have observed and my recommendations moving forward.

Context
The touch display SPI frames are fixed-size and 8192 bytes long.
The DAQ SPI frames are fixed-size and 576 bytes long.

By default, the SPI bus speed configured by the display driver is 25MHz
By default, the SPI bus speed configured by the DAQ driver is 16MHz

Here's what I have observed using 4.2.1 using the Touch Display module at the default 25 MHz speed:

First SPI request:

Sent: 0,0,3,0,7,86,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.[...]
Received: 128,91,110,119,97,97,97,97,97,97,97,97,97,97,97,97,97,97,122,101,116,46,100,105,115,112,46,49,46,48,54,0,[...]
Expected: 128,91,110,119,97,122,101,116,46,100,105,115,112,46,49,46,48,54,0,[...]

Second SPI request:

Sent: 0,0,3,0,7,86,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.[...]
Received: 0,[...]
Expected: 128,91,110,119,97,122,101,116,46,100,105,115,112,46,49,46,48,54,0,[...]

Subsequent SPI requests:

Sent: 0,0,3,0,7,86,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0.[...]
Received: 0,[...]
Expected: 128,91,110,119,97,122,101,116,46,100,105,115,112,46,49,46,48,54,0,[...]

Observations
1. in the first request, the received buffer is being corrupted as seen with the repeated '97'
2. subsequent requests with the same query string only return '0', indefinitely.
3. the data corruption and where it occurs in the buffer is random.
4. on occasions, the data is not corrupted and the display responds...until the next data corruption occurs.
5. connecting the display to either side of the GoBus yields the same results

Resolution
1. Dropping the SPI bus speed to 10MHz eliminates data corruptions and allows the display to work again
2. Anyone who is affected by this issue in 4.2.1 should try initializing their Nwazet modules like so (replace Socketx with the proper socket):

canvas.Initialize(GoSockets.Socketx, 10000); // 10 MHz

or if the issue persists:

canvas.Initialize(GoSockets.Socketx, 5000); // 5 MHz

3. The same recommendation applies to the DAQ

Conclusion
With release 4.2.1, the Netduino Go firmware introduced a change which made SPI communication above 10MHz unstable.
The Nwazet display and DAQ modules use ARM Cortex chips capable of high SPI frequencies and are configured to maximize SPI throughput by default, well above 10 MHz.
Other STM8S-based modules are unaffected by the change introduced in 4.2.1 because they work at much lower frequencies, typically much lower than 5MHz.

Erik. I respectfully disagree with your assessment of what is and isn't out of spec or a so-called "poor implementation" of a spec that never was until recently. Breaking changes happen. In all industries. Merci.

Chris,

So, first steps first: From what you posted, the blocking point in the current driver appears to be during enumeration. If you copy and paste the sample enumeration code from the RGB LED module driver into the [nwazet Touch Display driver, does that fix the issue?

As a first step, I'd prefer installing the 4.2.1 firmware on a stock Netduino Go and compare what I see on the wire against a 4.2.0 trace, without changing anything else.

A few questions:
Can the 4.2.0 SDK live side-by-side with the 4.2.1 SDK?
Is it possible to deploy and run existing 4.2.0 assemblies / code to a Netduino Go running the 4.2.1 firmware and expect things to work or is "recompiling the World" first a requirement?

-Fabien.

In this case, it would mean to the Netduino is rendering a bitmap, and then sends it to the module, which updates it immediately?

Yes, same method used today for rendering bitmaps. Just keep in mind that bitmaps get quite large at 16-bit / pixel and will eat up your flash / RAM in a hurry

For research purpose only: If need, would it be possible to order a batch of screens with custom logos?

Yup, it would be possible. You should email me at contact <at> nwazet <dot> com to discuss the details.

Cheers,
-Fabien.

Ah that wasn't exactly what I meant.. it's the yellow screen when it initializes i was referring to

Sorry, I misunderstood you. It can be replaced by recompiling the module's firmware with your own. You can do it using a variety of tool chains on Windows, Linux, Mac. I use IAR WorkBench but OpenOCD works too. You can then reflash the module serially using ST's own Windows utilities or if you're under Linux, a bunch of STLinkv2 alternatives such as http://code.google.com/p/qstlink2/ among others.

Ah I see.. and this is the case for all Go Modules, right?

Yes, the SPI latency aspect is unavoidable with Go modules: it's akin to sending a network packet from one computer to another. In the case of the touch display, the packet size is fixed at 8KB to accommodate sending bitmaps relatively quickly. Depending on your main scenario, you could change the default 8KB packet size to something smaller to reduce latency (that requires a firmware change too btw). What happens on the module itself with that packet is yet another story...

A good strategy to help reduce flickering during screen updates is to only update the zones of the screen that need to be refreshed. That will reduce the amount of data that needs to be processed each time.

I hope this helps.

Cheers,
-Fabien.

Hi Nicky, No worries About your questions: a. Yes, it can be replaced with the same touchscreen model. If you look at the display carefully, it's held in a metal cradle from which it can be extracted to swap a new one. It's also possible to replace the touchscreen with a regular display (same model but no touchscreen) b. Yes, it's normal for two reasons: there's SPI latency between the Netduino Go and the Touch Display module, then the set of commands sent to the display is interpreted and bit-banged onto the IC display driver bus (the STM32F205 does not have an FSMC peripheral, so bit-banging is the only option). This results in some flickering when refreshing the screen. I hope this makes sense Cheers, -Fabien.

Hi Nicky.

The VirtualCanvas class interfacing with the Touch Display hardware abstracts away the communication details, which is a good thing. However, the communication is still taking place over shared hardware resources: in this case, an SPI channel and an interrupt port for signaling readiness / command completion. If multiple execution threads need to access the shared hardware resources, they must be synchronized and serialized. Various methods can be used to synchronize threads on the .Net MF such as the lock(object) {} statement, event objects such as ManualResetEvent() and implementing a work queue to serialize hardware access requests. To simplify the design, improve application performance and reliability, I'd recommend dedicating a single thread to the management of the display and handling touch events.

What I'm describing here is true of any shared resource and in the context of a microcontroller, where there's no OS to queue I/O requests of behalf of application threads, it's up to the developer to orchestrate the show.

I hope this helps clarifying things a bit.

Cheers,
-Fabien.

Chris,

Really quickly, before I dig into the touch display module, we'll want to make sure to not use the GoSocket class in public function calls outside of your constructor. The standard GoBus constructor auto-detects the GoBus module if no GoSocket is provided to the constructor, and allows the user to specify a GoSocket reference if they want to use a module on a specific gobus port (including on a hub, with GoBus 1.5+ modules).

Please keep in mind that you released the GoBus 1.5 spec mid-September, long after the launch of existing, GoBus 1.0 compliant modules. You also claim on the "Introducing GoBus 1.5" page that:

GoBus 1.5 modules will work side-by-side on your Netduino Go with GoBus 1.0 modules.

Yet, here we are with a regression.

What method are you using to find a module UUID?

A straight up SPI transaction, which has always worked, as you know:

public void Execute(Synchronicity sync = Synchronicity.Synchronous) {
SetSynchronicity(sync);
int contentSize;
var spiTxBuffer = SendContext.GetBuffer(out contentSize);
if (contentSize >= MaxSpiTxBufferSize) {
throw new ApplicationException("contentSize");
}
GoBusIrqEvent.Reset();
Spi.WriteRead(spiTxBuffer, 0, MaxSpiTxBufferSize, _spiRxBuffer, 0, MaxSpiRxBufferSize, 0);
if (sync == Synchronicity.Synchronous) {
WaitUntilGoBusIrqIsAsserted();
}
}

As far as auto-discovery on the bus: the concept breaks down the moment you have more than one of the same device on the GoBus. It is a nice to have feature which should not be allowed to impact the existing ecosystem.


-Fabien.

Troll, All Nwazet modules, by design, work at the lowest level of the .Net MF, only requiring a dedicated SPI port and an interrupt port. In other words, we're 100% GoBus 1.0 compliant. This enables our modules to be used across all Netduino SKUs, (Netduino, Netduino+(2), Netduino Mini, Netduino Go) starting with firmware revision 4.1.1. If a breaking change affecting SPI and/or interrupt ports is introduced with a Netduino Go firmware update, we have no control over it. Obviously, a breaking change of that nature will potentially impact any type of device using a straight SPI / interrupt port. Chris, Have you actually tested firmware 4.2.1 with the Nwazet Touch Display and the Nwazet DAQ modules before releasing this firmware? -Fabien.

Chris, Do you do regression testing on existing Go modules before releasing Netduino Go firmware updates? -Fabien.

Ulrik,

I felt that your reaction was offensive and unfair. I'm only interested in one thing: getting our users unblocked asap and for issues such as this one to never repeat themselves in the future.


Software releases generally follow a process which involves regression testing to mitigate potential user impact when changes are introduced. It's a reasonable thing to ask if regression-testing occurred because it is a standard best practice in our industry. No one should be offended by that and I am confused as to why anyone would perceive my question to be a wrongful attempt at keeping anyone waiting.


As far as moving on, I'd like that very much too.


-Fabien.

Chris,

We do have a DAQ module, but it's currently undergoing GoBus compliance testing so I can't pull it until that's done.

I have no idea what that means, unfortunately. Can you please clarify?

So we weren't able to do any testing with those two modules.

This is unfortunate for Netduino Go users at large. Such breaking changes should not be introduced.

We are here to assist module manufacturers with their driver code where possible. Whether you want to send us hardware to help diagnose the issue or if you want to send us info on the issue you're experiencing in the module driver, we're happy to help.

As I stated it earlier, our modules worked just fine until this release broke either SPI or interrupt ports or something else in the Netduino Go firmware that we have no control over. Regression testing with existing Netduino Go modules should be a best practice put in place as part of the Netduino Go firmware release process, for the sake of our mutual customers.


-Fabien.

Quoting Troll:

Just in case you hadn't heard what the problem is. I am getting it to hang on the Initialize call on both the DAQ and Touch Screen. If I flash it back to 4.2.0 it works, 4.2.1 doesn't. Same issue was seen by Gut when he tested. it.

There's no exception being thrown: the code just hangs on the Initialize() call trying to ID the module:

        public static void Main() {
            var canvas = new VirtualCanvas(TouchEventHandler, WidgetClickedHandler);
            canvas.Initialize(GoSockets.Socket5);

or

namespace DAQmodule {
    public class Program {
        public static NwazetDAQ daq = new NwazetDAQ();
        public static void Main() {
            daq.Initialize(GoSockets.Socket5);

	<...>

Initialize() attempts to retrieve an SPI packet containing a valid module ID, matching the driver (per the GoBus 1.0 spec). All of our modules have worked this way from day one.

        public void WaitUntilModuleIsInitialized() {
            while (!_moduleReady) {
                Execute(Synchronicity.Asynchronous);
                if (_spiRxBuffer[0] == 0x80 && 
                    _spiRxBuffer[1] == '[' && 
                    _spiRxBuffer[2] == 'n' && 
                    _spiRxBuffer[3] == 'w' && 
                    _spiRxBuffer[4] == 'a' && 
                    _spiRxBuffer[5] == 'z' &&
                    _spiRxBuffer[6] == 'e' &&
                    _spiRxBuffer[7] == 't' &&
                    _spiRxBuffer[8] == '.' &&
                    _spiRxBuffer[9] == 'd' &&
                    _spiRxBuffer[10] == 'i' &&
                    _spiRxBuffer[11] == 's' &&
                    _spiRxBuffer[12] == 'p') {
                    if (_spiRxBuffer[17] != _identifier8bitCrc) throw new ApplicationException("SPI data corruption");
                    _moduleReady = true;
                    return;
                }
                Thread.Sleep(200);
            }
        }

This is a basic SPI exchange which doesn't rely on any other .Net MF feature (i.e. InterruptPort).

-Fabien.

Chris,

A straight up SPI transaction, which has always worked, as you know

Ah, that could cause troubles. Please grab a copy of the RGB LED, Potentiometer, or Piezo Buzzer module source code from the Wiki for an example of the standard enumeration method for GoBus. We'll be happy to help you update your driver if you'd like.

Can you please clarify how a straight up SPI transaction is suddenly an issue in a system that is purely SPI-based?

What has changed between 4.2.0 and 4.2.1 that affects SPI in the context of the Go?

Why are GoBus 1.5 changes allowed to break GoBus 1.0 devices, when the claim was made that a side-by-side experience will remain functional?

If 4.2.1 was designed to introduce a fundamental breaking change, which should not be the case for a minor release such as this, why were we not given the courtesy of a warning well in advance to prevent any customer impact?

-Fabien.

Ulrik,


Thank you for sharing your wisdom with us and showing us the error of our ways. You're clearly experienced in ways that I cannot fathom. Please, by all means, enlighten us all on how to resolve a software regression we have no control over...


-Fabien.

Nice job Matt It's good to see the module ecosystem growing. -Fabien.

Hi Matt,

Can you please share a link to the license (covering hardware, C# drivers and firmware) under which Komodex modules are released? I may have missed it, but I did not see it on your site.

Thanks,
-Fabien.