Illishar

I've implemented a small sample that shows how to reset the processor through direct register access. And it works ... only problem is that the usb/debug driver doesn't boot up after reset. Hmmmm ...

Hello there,

Just a small info (yet another) to those who wants to compile the Netduino source.

- Start compiling with the CodeSourcery (GCC 4.2) compiler, which is supported by Microsoft.
- To make it compile, you most likely need to edit the memory layout. This is due to changing and different compiler outputs.
- The files are:
C:\MicroFrameworkPK_v4_1\Solutions\Netduino\TinyCLR\scatterfile_tinyclr_gcc.xml
C:\MicroFrameworkPK_v4_1\Solutions\Netduino\DeviceCode\Blockstorage\Sam7X_blockstorage\Sam7x_Bl_Config.cpp

In the sam7x file you'll find this:

const BlockRange g_SAM7X_BS_BlockRange[] =
{
    { BlockRange::BLOCKTYPE_BOOTSTRAP       ,  0,  5 },		
    { MEMORY_BLOCKTYPE_GCC_SPECIAL_BOOTSTRAP,  6, 14 },		
    { BlockRange::BLOCKTYPE_CODE            , 15, 44 },		
    { MEMORY_BLOCKTYPE_GCC_SPECIAL_CODE     , 45, 46 },		
    { BlockRange::BLOCKTYPE_DEPLOYMENT      , 47, 60 },		
    { BlockRange::BLOCKTYPE_STORAGE_A       , 61, 61 },	
    { BlockRange::BLOCKTYPE_STORAGE_B       , 62, 62 },	
    { BlockRange::BLOCKTYPE_CONFIG          , 63, 63 }
};

Which doesn't fit when using GCC4.2. If you look at it it will tell you, that the BootLoader will take up either 6 blocks (RVDS) or 15 blocks (GCC). This is mostly correct. However depending on what you're trying to do, the BootLoader might not be of interest to you. The TinyCLR is. Which means that you can keep your SecretLabs compiled RVDS BootLoader (much smaller) and combine it with your own TinyCLR.

I've therefor changed my setup to this:

const BlockRange g_SAM7X_BS_BlockRange[] =
{
    //
    { BlockRange::BLOCKTYPE_BOOTSTRAP       ,  0,  5 },		//  ~50k (RVDS BootLoader)
    { BlockRange::BLOCKTYPE_CODE            ,  6, 49 },		//  ~360k = 0x0C000
    { BlockRange::BLOCKTYPE_DEPLOYMENT      , 50, 62 },		//  ~106k = 0x64000
    { BlockRange::BLOCKTYPE_CONFIG          , 63, 63 }
};

Depending on the size on your TinyCLR you might have to alter the CODE and DEPLOYMENT addresses.
Yes, I've removed the STORAGE_A and B. They're official areas in the netmf, but they're not currently in use by the Netduino.

When you've made this change, you also need to adjust the scatterfile. This is what I use:

    <Set Name="Heap_Begin"      Value="0x00010000"/>
    <Set Name="Heap_End"        Value="0x00017FF8"/>
    <Set Name="Stack_Bottom"    Value="0x00018000"/>
    <Set Name="Stack_Top"       Value="0x0001FFF8"/>

    <If Name="TARGETLOCATION" In="FLASH">
        <Set Name="Code_BaseAddress"    Value="0x0010C000"/> <!-- This is start TinyCLR -->
        <Set Name="Deploy_BaseAddress"  Value="0x00164000"/> <!-- This is start app code -->
        <Set Name="Code_Size"           Value="%Deploy_BaseAddress - Code_BaseAddress%"/>
        <Set Name="Config_BaseAddress"  Value="0x0017E000"/>    
        <Set Name="Config_Size"         Value="0x00002000"/>
        <Set Name="Valid"               Value="true"/>
    </If>

Notice that the Heap and Stack is only using half of the ram? Yeah ... fancy that.

If you make it compile then just open up your MFDeploy and flash your own ER_FLASH and ER_CONFIG. They're placed in:
C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.hex\

Hello, Just a small observation: If you have Microsoft Code Contracts installed on your computer, it might give you trouble when compiling the netmf PK. Odd, but there you have it.

I'm doing some brainstorming with direct port access, from within the Netmf. I don't yet know if it's possible. The theory is sound though. If we can access the native ports (mem access), we'll be able to create 'native' drivers, without messing with the native fw. This ofc will not be performance friendly, but then again, many functions/drivers don't need performance. And these 'Managed native' drivers won't take up space in the fw, when not in use. (Cool) The attached project has not yet been testet. (My board is currently out of reach.) This is just work in progress. (Using the forum as a mid way storage

(This thread should go to the comming RTOS thread.) I have a question in regard to low level Netduino setup: The uarts. The Nut/OS has defined the following: - uart0 is at PA0 and PA1 (Netduino COM2) - uart1 is at PA5 and PA6 (Doesn't seem to be accessible on Netduino.) - dbgu is at PA27 and PA28 (Netduino COM1) The dbgu and uart0 works fine in Nut/OS. But one cannot read from a dbgu. (It's a debug driver.) So I'm wondering how to enable a real uart driver on PA27 and PA28. I've tried inserting the dbgu pins into the uart1 driver, but it doesn't seem to be enough. (But perhaps I've messed up something.) Any thoughts? PS. I have no idea how any of this works. I'm just guessing.