Core System Datasheets

We’re working on getting datasheets for all of our core systems (G30 SoC, G80 SoC, G120 SoM, and G400 SoM) that covers the important details of each. Detailed information will be found in a NETMF manual or the help documents section.

You can see the first draft of the G120 and G120E datasheet at

We appreciate any feedback you have on it from spelling or grammar issues to features you think need to be detailed for the module for anyone who might use it.

Do you guys have like a copywriter? A person dedicated to preparing documents?

This is an add on. The manual is basically the netmf book, with updates to come. The datasheet doesn’t teach nermf but has some very important set of details.

draft of the G120 and G120E datasheet:
Page 20
11.1 Licensing
row 3
and the G120 SoM
must be
and the G120E SoM

draft of the G120 and G120E datasheet
Page 15
7.26 Direct Memory Access
’Not all functionality of the processor is available as some functions may be used or configured internally for use in NETMF.’

I presume it may be dependent on the NETMF version, but are some registers/memories granted free for the user application over time?

@ SouthernStars - Thanks for the catch. I’m not sure what you mean by “are some registers guaranteed free over time?” though.

‘Not all functionality of the processor is available as some functions may be used or configured internally for use in NETMF.’

It is about “Not all … and…some functions …”.

Which ones? and worse; it may change in the future as the NETMF evolves.

In other words, are there registers/memories ‘user reserved’, today and in the future to avoid collisions with the NETMF…

I would like to see a few words written about this:

@ iamin - We do not configure the brown out circuit on any of the systems, so you can consult the processor’s manual for the defaults.

@ SouthernStars - We do not document which parts of processor we use in NETMF, nor are there user reserved sections outside of RLP. Because we use so much it, the list would be too large to maintain. Using register access to configure the device is a very advanced topic. Any use of them is case by case on what issues could come up.

For example:
Timers are a common source of issues among users. We use some internal timers for PWM, time keeping, and other functions. We do not document which timers we use because it could change between firmware releases for any number of reasons. If you use a timer yourself and find other functions of the board stop functioning or your use of the timer doesn’t behave as expected, it is likely that we are using it ourselves and you are best using a different one.

Hi John I understand that it can be difficult to describe which timer is used or not but it is a must have. Performing exhaustive test each time we want to use a new timer is not satisfactory. Test coverage can’t be 100%. I often add a new feature in a rush (custom order a day/week before shipping). If I know that a timer is used by the core I would not use it again that’s it and try to use an other one.

1 Like

@ John - I already know that - you have explained me that before. But you could say this in that document as well, just to keep “everything in one place”.

@ iamin - There are many features on a chip that we do not configure or expose through our libraries, brownout is just one of them. We do mention in the datasheet that you should consult your processor’s manual for advanced information.