G400(on FEZ Raptor) - error during application deployment by MFDeploy(or FEZ Config)

NETMF & Gadgeteer
1

Hi all,
I have tried to deploy my application to the FEZ Raptor using MFDeploy(and also using FEZ Config) and there is an error during deployment.

Here is my configuration:
FEZ Raptor connected via USB and powered also through external adapter just for sure(but tried also without adapter ):
TinyBooter 4.3.5.0(I am using 4.3.5.0 because of some troubles with 4.3.6.0 but it should not be a problem here)
TinyCLR 4.3.6.0
FEZConfig 2.0.6.0
MFDeploy 4.3.1.0

1)I can deloy/debug fine with VS2012.
2)I can also create a hex file of my app with MFDeploy (Menu->Target->Application Deployment->Create Application Deployment)
I do not use any key files, so I get no .sig file.
I can create the same file also from FEZ Config in Deploy(Advanced) by Create HEX file .
(By the way the HEX file has cca. 560kBytes while during deployment from VS2012 there is mentioned application size cca. 180kByte so why is here so big difference? Or is it application + firmare together?)

  1. Now I have tried to upload that file back to the Raptor by Deploy HEX file(s) in FEZ Config and there were PopUps:
    a)Connecting to device
    b) Erasing sector 0x00294000
    c) Rebooting…
    d) then Erasing sector 0x00294000 forever…(only Task Manager and End task helps here)
    I have also tried to only Erase the application first in FEZ Config before Deploy but with the same result.

  2. I have tried the same with MFDeploy by selecting HEX file and pressing Deploy:
    PopUps:
    a)Connecting to device
    b) Erasing 0x00294000
    c) Rebooting
    d) Erasing 0x00294000
    e) Error: Unable to deploy to device

I have tried it several times(also with RESETing/connecting/disconnecting Raptor USB) with the same result.
And after this I am still able to deploy/debug by VS2012.

Do you have any idea what could be wrong or has somebody tried to successfully update application on Raptor(G400-S) by FEZ Config or MFDeploy?
I need to update only application(Firmware is not necessary).

Thanks for your help.

2

@ mhstr - Can you hold down LDR1 and then apply power to the board? That should keep the board in TinyBooter mode. Try to deploy the hex file then.

3

I will test it but even if it works like that then I do not understand how it can be used by the customer becuase I would like to send new application to him and normally the Raptor (our board with G400) will be covered so it would be very difficult for the customer to hold some key.

4

Can you expose a button in your design and UART ? – See chapters 4,5,9 in the G400 user manual https://www.ghielectronics.com/downloads/man/G400_User_Manual.pdf

5

Thank you John and Jeff!

After holding LDR1 down during reset I was able to activate TinyBooter mode and it was possible to upload hex file. But the strange thing is that it was only possible to do it through USB.
When I tried COM1(PA25 grounded during RESET) then COM1 was accessible only in TinyCLR, it was not accessible in TinyBooter - both FEZ Config and also MFDeploy was not able to make a PING.

But I have tried to update TinyBooter to the latest version 4.3.6.0(previous was 4.3.5.0) and now everything worked - USB and also COM1 in TinyCLR and also in TinBooter!

And now is even possible to upload new application (HEX file) directly from TinyCLR(with TinyBooter 4.3.5.0 it was only possible from TinyBooter and through USB).

So something tells me that it is not possible to combine different versions of TinyBooter and TinyCLR.

I thought that in case GHI releases new firmware I will simply send it together with new recompiled application to the customer and he will simply update new firmware(after activation of TinyBooter by LDR1 during RESET) and application eiher from TinyBoother or from new updated TinyCLR.
But in case that also TinyBooter needs to be updated then I am sure customer will give it up because it is out of the customer skills - SAMBA, command line etc.

Could you please explain me and probably also to the others the rules of TinyBooter and TinyCLR version combination?

Thanks.

6

@ mhstr - There are no hard rules for different versions of TinyBooter and TinyCLR. There are times when a change to TinyBooter requires that you update, sometimes not. For 4.3.5, there was a bug that with the serial interface on the G400 that was fixed in 4.3.6, that you saw.

We are working on removing the need of the samba program to update TinyBooter on G400, but we cannot promise anything yet.

As for your original issue, deploys failing in TinyCLR mode are something we are looking into but don’t have a fix for yet.

7

@ John - Thanks John for clarifying these things.
Maybe some logical question based on your response…

If we use GHI nice feature - In Field Update - how is it solved these dependences? You said sometimes is necessary to update both: Firmware(TinyCLR) and also TinyBooter. But if I am not totally wrong IFU can update only TinyCLR and managed code(application) so we are actually not able to update TinyCLR and application correctly under some circumstances using IFU (=if TinyBooter must be also updated).

Is there any workaround for such a situation when using IFU?

8

@ mhstr - Sadly there is not a workaround. You will need to manually update TinyBooter if there is an update.

That said, our plan going forward is to change TinyBooter as rarely as possibly to avoid situations like these. Adding TinyBooter support to IFU is also something we are considering, but no promises.