G400 bootloader… the wait is over!

After a long await, the GHI boot loader is now available for G400 family of products! Developers can now easily update the G400 SoMs without the need for the SAM-BA tools. The whole update process is simple and can be done using FEZ Config. FEZ Raptor owners will find this loader useful as the LDR buttons will now function properly.

The loader has been well tested but it is still in beta. It is not recommended to ship on products just quite yet, but we encourage everyone to try it and provide us with feedback, both good and bad.

Deploying and using the loader is documented in the support document located here.

Support Document: https://www.ghielectronics.com/docs/336/installing-the-g400-bootloader

6 Likes

@ Gary -

Thanks guys!

Love my Raptor and now it will be even better…

:clap:

@ Gary -

You may want to mention that for TeraTerm New-Line Transmit:
needs to be set for CR.
Using CR+LF causes the Flash Bootloader.bat to send Canceled

@ willgeorge - Thanks, we’ve clarified that CR is the proper line ending.

After a long wait :clap:

Hello,

Is it possible to copy bare metal code to sram from .netmf code, then stop .netmf code and run code from internal sram on G400? I need it to run basic functionality with low power consumption (core clock is 500 Hz). When I need fully functionality, then reset processor and run .netmf. Or is there another way to switch between startup bare metal code and .netmf?

@ andre.m - No, in RLP you don’t change core clock to 500 Hz. You must have bare metal code which run in internal SRAM.

Access RLP and never return. You can do anything

@ Gus -

anithing? try this

PMC->PMC_MCKR = (PMC->PMC_MCKR & ((uint32_t)~PMC_MCKR_CSS_Msk)) | PMC_MCKR_CSS_SLOW_CLK ;
while ( !(PMC->PMC_SR & PMC_SR_MCKRDY) ) ;
PMC->PMC_MCKR = (PMC->PMC_MCKR & ((uint32_t)~PMC_MCKR_PRES_Msk)) | PMC_MCKR_PRES_CLOCK_DIV64 ;
while ( !(PMC->PMC_SR & PMC_SR_MCKRDY) ) ;

Sorry for my English. I have a reliable code that I have verified. I reached with it consumption 12 mA @ 3.3V. The code I record with SAM-BA to the internal SRAM and tuned via DBGU.

The problem occurs when via RLP or AddressSpace.Write load same code into the internal SRAM, then I set the PC to 0x300000. Before uploading, I turned off all peripherals, disable interrupts. The program will start, but after a while will stop. I don’t know what is done in the background environment NETMF. How do you shut it down completely NETMF? NETMF environment uses internal SRAM?

By the way, why RLP address begins at 0xA0000000 and not somewhere between 0x20000000 and 0x28000000?

What makes DeepSleep? When the G400 awaken watchdog reset it. Is this correct?