The device is in Loader mode. in FEZ config

Is this the device in “bootloader” mode?

I’m strugling getting the firmware on some new G120 based hardware PCB’s i received for testing. :S

I first update the bootloader with teraterm, but the TinyBooter say’s 4.3.1.0 after transfering the loader.ghi ? :open_mouth:
If i next look in FEZ Config i see the device G120_G120 as USB device :slight_smile:
I check device for update and there it say’s:

 Loader (TinyBooter) version information: 
 4.3.8.1 on this computer.
 4.3.8.1 on this device.
 >>> The Loader (TinyBooter) is up to date. <<<
 

 Firmware (TinyCLR) version information: 
 4.3.8.1 on this computer.
 Firmware (TinyCLR) Version:  Not present on the device.
 The device is in Loader mode.
 Click on 'Reboot CLR' under the Advanced menu to reboot the device.

So the message “The device is in Loader mode.”, if i do the reboot from the advanced menu i end up in the same mode :frowning:
If this is actualy the bootloader mode then problably something is wrong with the LDR pins.

Thanks.

@ David@ Leclanche - Updating the bootloader through TeraTerm erases the firmware and only deploys TinyBooter. You still need to go through the Firmware Update step in FEZ Config. When FEZ Config says “The device is in loader mode” it means it is in TinyBooter and that it the firmware is not running.

Alternatively, you can have FEZ Config update everything for you by going to Loader Update under the Advanced menu.

Hi John,

I put it in bootloader mode and did the update with the advanced update, all the steps went fine, message update completed.
Then i reboot the board, in FEZ Config do the "check device for update :

Connecting to device G120_G120.
Please wait, this may take a few moments

Then the Device selection box (where G120_G120 was) is empty for a few seconds, i get :

Failure - Device is not connected or not responding.

In the device manager is see the GHI NETMF Interface device go away and come back like if the device is doing a reboot…

@ David@ Leclanche - If you ping the board, what does it say?

  • 1 Device is listed in device manager and in FEZ Config
  • 2 Ping
  • 3 Device drop down is going from G120_G120 to blanco
  • 4 Failure
  • 5 (not in screenshot) Device is gone in device manager and comes back as in a reboot cycle…

There is no application software deployed on the device at this point, it’s a clean board comming from production.

I switched from USB to UART debugging and connected Teraterm again, then is see the exceptions looping (attached)


EXCEPTION	0x06:
cpsr=0x00000000
pc	=0x1000ff58
lr	=0x00005001
sp	=0x1000a588
r00	=0x00000101
r01	=0x00000100
r02	=0x00000000
r03	=0x00000008
r04	=0xa0000478
r05	=0x00005001
r06	=0x1000ff58
r07	=0x00000000
r08	=0x1000ff7c
r09	=0xa0139430
r10	=0x1000ff58
r11	=0x7fa3d7a1
r12	=0xa0000478

@ David@ Leclanche - Did you erase and update the firmware immediately before you pinged the board? If you do another erase and update cycle without pinging or checking for updates, do you get those exceptions immediately after?

Erase with Teraterm you mean?

@ David@ Leclanche - Either TeraTerm or FEZ Config.

Attached the results of a clean Teraterm Erase, transfer loader.ghi and output after bootloader startup and normal startup (debugging in UART mode)

@ David@ Leclanche - And after you deploy the firmware in FEZ Config without pinging or checking for update, do you see those exceptions over serial?

Could this be related to a design issue as you said this is a custom board? Has this design worked before? Is there more than 1 of them causing this issue?

How have you gotten pin 16 wired (Mode)?

How about pin 53 (reset)?

Are your USB data lines run as differential and equal length or as best as?

After the erase and deploy i booted the device in bootloader moder (+ USB debugging) and i have the virtual bootloader com port in device manager.

Next 1-2-3-4 in the attached screeshot, reboot and connected Teraterm and there i have :

 
EXCEPTION	0x06:
cpsr=0x00000000
pc	=0x1000ff58
lr	=0x00005001
sp	=0x1000c008
r00	=0x00000101
r01	=0x00000100
r02	=0x00000000
r03	=0x00000008
r04	=0xa0000478
r05	=0x00005001
r06	=0x1000ff58
r07	=0x00000000
r08	=0x1000ff7c
r09	=0xa0139430
r10	=0x1000ff58
r11	=0x00000002
r12	=0xa0000478

@ David@ Leclanche - Can you redownload and reinstall the SDK to verify the firmware files are not corrupt? Is this board new from us or has it been in use?

The SOM is a new one, but the board is a redesign, but the first proto’s worked flawless with 4.3.6

I received new assembled boards yesterday but i also upgraded the project to 4.3.8, the upgraded project and platform deployed flawless to the old PCB’s so the downloaded package should be ok.

Let me compare some other boards tomorow to see if they behave the same.

@ Dave McLaughlin - the redesign worked fine with 4.3.6 but i only tested 1 board today from a small production series.
I try some other samples first to see if the behaviour the same, thanks.

I flashed an other board from the same series today and this was ok… :whistle:
The electronic boy’s going to replace the G120 SOM and see if it’s fixed.

Could this be caused by bad ESD protection during production ? or that the PCB is baked 3 times?

Thanks for the help John

@ David@ Leclanche - ESD could cause any number of issues and will be near impossible to track down. Do you bake the G120 three times in your own production once you receive it from us?

Normal this would be 2 times if we do proto series in house but in this case 3 because of missing components.
Anyway, we replace the G120 on the first board and it’s working fine now ;D