We are still delivering versions of our development tools built with Microsoft Visual C++ 6.0 since there are lot of educational users worldwide using Windows XP.

If you installer filename is 'setup.exe', then the software was built with Microsoft Visual C++ 6.0. If the installer is an MSI file that requires Windows 7.0 or above then the software was built with Microsoft Visual Studio 2017.

A program may store persistent data in on-chip flash and in a previous blog I showed you how to initialized the simulating on-chip flash from Javascript.

Programs that also or instead store data in SPI memory may want to simulate this off-chip memory too. So in the next few blogs I will show you how to simulate SPI memory with Javascript.

My example program is using bit-bashing to control the SPI memory and it is writing the BSRR register of port B to do this (STM32Fxxx chip). So my first step it to create an event handler which will be called whenever my simulating program writes to g_pGPIOB->BSRR. I can get the Embedded Development Studio to create the appropriate Javascript code for me. To do this, I right mouse click on my Javascript source file and from the context menu that opens select jState Code Creation Wizards->GPIOB.

When I click on GPIOB, the code creation wizards opens:

This allows me to see all of the events and properties available for jState.gpiob.

I am interested in the first item and when I select it I see the source code (with comments) that the wizard will generate for me. I click on Insert and this Javascript code it is placed into my Javascript file.

var writeGpiobBSRR = function(event) {
// the Bit Set-Reset Register (BSRR) is being written
// event.data contains the value being written to it
// jState.gpiob.m_nODR has not yet been updated
// add your javascript code here:
}
jState.gpiob.addEventListener("writeBSRR", writeGpiobBSRR, false);

This gives me both an event handler and the code that will register that event handler.

Now, whenever my simulating program writes to the BSRR register of port B, my event handler will be called.

You might want to put something like console.log("Event handler called\n") into this event handler for test purposes.

With these two arguments I can determine the value of the output data register both before and after the write to BSRR. I do this in function updatePort below. Then I will know the levels of each port B pin and whether or not they are rising or falling.

Today we updated the jState support within our Cortex-M3 and Cortex-M4 extensions to allow access to on-chip memory from Javascript.

The jState code creation wizard for the on-chip memory (accessible by right clicking on the Javascript file) will tell you what functions are available.

The image below shows code that it has created for us to set the on-chip memory read and write addresses to 0XE0000 and the increment on both read and write to 2. (To increase the read or write address by 2 after each read or write.)

Our intension is to write a table of values into the on-chip flash memory sector at 0XE0000 - our simulating firmware is expecting this table to be in place at startup. So with a bit of manual editing we have the following Javascipt code:

When step into the simulator we can see that the data has been written into the correct memory locations:

By the way, to create the initial Javascript file select File->New and in the Files tab select Javascript Source File. The Embedded Development Studio will populate the file name field for you so just click OK.

The GUI parts of our Development Suite for ARM have been rebuilt using Microsoft's Visual Studio 2013. That's over 80 DLLs as well as the Embedded Development Studio executable itself and so it was not an insignificant task.

For the embedded developer, this brings two major benefits:

1. The simulator can be graphically extended using Microsoft's latest Visual Studio 2013, including the free Community edition

2. The Cortex-M3 and Cortex-M4 simulations can also be extended using state-of-the art Javascript (see jState)

Unforunately it does mean leaving behind operating systems prior to Windows XP - the minimum requirement for these latest editions of the Development Suite for ARM is Windows XP SP3.

Continuing with my theme of yesterday where I wrote to the U40 MSP23017 soft switch chip to enable SW4 and SW5, I will show you how to read the register values from this U40 chip.

I've created two subroutines - WriteRegisterValue() and ReadRegisterValue() to make the main function clearer.

You will see below that I am writing to register 0X15 which is the output latch OLATB register whereas yesterday I wrote to register 0X13 GPIOB. But if you read back the value of register 0X13 after you have written to it, you do not see the value that you have written. Instead you have to read OLATB to see this value. The MSP23017 data sheet explains that a write to GPIOB is actually a write to OLATB and a read of GPIOB reads the port pins. So to avoid confusion, I write directly to OLATB instead.

We are developing support for Analog Device's ADSP-CM40x microcontrollers.

We received our ADSP-CM408F EZ-KIT Lite board on Monday and set about investigating the operation of the JTAG/SWD debugger interface. Pretty soon we could download and run programs in SRAM. (Lots of omissions and errors in ADI's reference manual though so it took a lot longer to get there than it should have!)

As usual during such developments we incrementally work our way though the peripherals adding register definitions, simple context menu wizards, simulation and so on, testing that things work along the way.

There are lots of examples for this board provided by ADI but we couldn't find anything remotely simple. So here is how to read the input switches SW4 and SW5 and illiminate the LEDs LED1 and LED 2:

The Crossware USB drivers for the FireFly and Jaguar debug interfaces are now signed and so fully compatible with Windows 8 and 8.1.

Our experiments with Windows 8.1 indicate that it does not display a 'Found New Hardware' message when a new USB device is inserted into the PC. In such cases it is necessary to open Device Manager to manual install the driver.

One approach is as follows:

To open Device Manager, press the Windows key to bring up the tiled desktop (if it is not already showing). Press <space> and type 'drivers'. In the search list that is displayed, select 'Update Device Drivers'. Device Manager should now open.

If you see 'Other Devices' listed in Device Manager, select it. You should then see the FireFly or Jaguar device listed. (If you don't see Other Devices, and you cannot see the entry for the FireFly or Jaguar device try unplugging and plugging the device back in to see which entry is removed and then added back into Device Manager.)

Right mouse click on the FireFly or Jaguar device entry and select 'Update Driver Software' Then select 'Browse my Computer for Driver Software'.

Now you can browse to and select the folder containing the appropriate Crossware signed driver. Follow the instructions to install the driver.

How can you tell if the Crossware driver is signed?

We do not actually sign the driver DLLs, these are signed by Microsoft. We sign the .INF file. The presence of a .CAT file matching the name of the .INF file indicates that the .INF file is signed. For the FireFly driver for 64-bit Windows you would see this: