Problems regarding to .Net Micro Framework 4.4 running on STM32F7

[weixiongmei]

I'm porting the .Net Micro Framework 4.4 to the STM32F7, and got most of the drivers done, such as USB, external SDRAM, executing application on external QSPI flash(It seems like it is much faster than executing on the internal flash, it takes less than a second to deploy a 450KB C# application), LCD, Touch Screen. But there're couple strange problems.

1. The .Net Micro Framework Deployment Tool only supported up to 4MB of flash, when erasing the flash that's larger than 4MB, an error message will occured. I'm sure the Flash driver on the embedded side is good, i could erase every sector by using the native code.
2. The firmware will radomly freezed about 45 minutes with Debug Build, and about 5 minutes with Release Build.
   If anybody experieced for porting the STM32F7, please give me a hand, very appriciate!!!!!

The code would be shared to the community once got it running stable.....

Please reply in this thread or contact me at weixiongmei@outlook.com

[weixiongmei]

Just Got it fixed, everything seems working perfect at the moment, except the .Net Micro Framework Deployment Tool could not exceed 4MB..

[SytechDesigns]

Hi , I have been looking at M7 ports as well. Initially I updated the mf4.3 port, but I do get strange effects on the LWIP networking. For instance on a ping response from a PC ping. The first reply usually takes more than 400mSecs, but second reply can come in straight away, this gets repeated for pings 3 and 4 - but because of the slow response windows effectively reports a 50% loss - due to the time outs. However DHCp seems ok. On a TCP/ip 'echo' test, you can echo 100's of messages from a pc test app without loss - but the response time of the echo's is terrible - about 100mSecs.
I have drivers for USB SPI uart - basically everything except for I2c - not completed yet.

Any chance we can look at your source project? Compare notes?
ps - did you ever get your cortex M0 port going?

Regards Sytech Designs staylor@sytechdesigns.com

[weixiongmei]

Hi Sytech,
My M0 has been using for real product for a long time.

You ported the M7 to the MF4.3? What ethernet chip you're using for the networking? My suggestion for your problem is do the debugging for you firmware, place the break points to the ethernet driver and trace the code step by step, then you may know what's casuing a lot of time for the response. I think your problem is not that difficult to get it fixed. All the best!!!!

[weixiongmei]

Just got the 4MB flash problem fixed, but it must be smaller than 16MB(Even equal to 16MB the error would still occures).

[weixiongmei]

With the MF4.4, no matter what, this issue always happens, does anyone know what's wrong with it? Even with the stm32f407 & stm32f429 discovery...

Looking for a device on transport 'USB'
Found device port 'USB' with ID '04b7dbc0-26a6-43a2-927d-003ad8981549' for transport 'Usb'
Starting device deployment...
Attempting to connect to device 'USB:Kirin' Iteration 0
Opening port \?\usb#vid_1991&pid_0001#5&2c09018&0&2#{d32d1d64-963d-463e-874a-8ec8c8082cbf}
Attaching debugger engine...
... debugger engine attached!
Querying device assemblies...
Found Assembly mscorlib 4.4.0.0
Found Assembly Microsoft.SPOT.Native 4.4.0.0
Found Assembly Microsoft.SPOT.Hardware 4.4.0.0
Found Assembly Microsoft.SPOT.Hardware.Usb 4.4.0.0
Found Assembly Microsoft.SPOT.Hardware.SerialPort 4.4.0.0
Found Assembly Windows.Devices 4.4.0.0
Found Assembly Microsoft.SPOT.Graphics 4.4.0.0
Found Assembly Microsoft.SPOT.TinyCore 4.4.0.0
Found Assembly Microsoft.SPOT.Touch 4.4.0.0
Found Assembly Microsoft.SPOT.Ink 4.4.0.0
Found Assembly System 4.4.0.0
Found Assembly Motorcycle 1.0.0.0
Found Assembly Microsoft.SPOT.Net 4.4.0.0
Adding pe file C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.4\Assemblies\le\System.pe to deployment bundle
Adding pe file C:\Users\Weixiong Mei\Documents\Visual Studio 2015\Projects\Smart Console\Motorcycle\bin\Debug\le\Motorcycle.pe to deployment bundle
Adding pe file C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.4\Assemblies\le\Microsoft.SPOT.Net.pe to deployment bundle
Attempting deployment...
Incrementally deploying assemblies to device
Deploying assemblies for a total size of 339700 bytes
Assemblies successfully deployed to device.
Restarting interpreter...
Attaching to device...
Waiting for device to initialize...
The debugging target and the debugger engine failed to initialize because of unspecified device errors.
The debugger engine thread has terminated unexpectedly with error 'Could not reconnect to the debugging target after rebooting it.'.

[SytechDesigns]

Years ago when we changed the flash from 4mg to 8mg on the Meridian, we ran into this problem. Lorenzo T. Explained it at the time - but I can't remember the details. However I am on route to NZ and will be seeing Martin Welford. I'm sure he will remember. But I won't be there for about a week - so won't get an answer until then ( going a scenic route!)- so if you get no answer before then, maybe I can help then

[weixiongmei]

Hi Sytech,
Ok, if you know how to solve it, please give me a hand, i can't get above 16MB of flash at the moment. Thanks.

Have you ever thought to improve the performance of the .Net MF? I can only get the .Net MF running 2 - 3 times faster than the orinal source...... Want to make the .Net MF more usable............

[weixiongmei]

Just got the .Net MF 4.4 running 6 - 7 times faster on STM32F7 comparing to the original .Net MF 4.4 source code running on STM32F4. (Same frequency..) Maybe in the future with STM32H7, we could get it running 10 - 15 times faster at 384 Mhz, that would be fast enough for many projects. Of course, the STM32F7 & STM32H7 is much more expensive...

[piwi1263]

How did you achieve this ?

Care to fill us in on the details ?

[weixiongmei]

@piwi1263
you can take the advantages from the STM32F7's L1 Cache, the .Net MF would running 3 times faster with the original source...... The other improvements have to be deal with the interpreter....

[SytechDesigns]

Some questions on the original problem...

1. The problem of the 4Meg limit.. what was the problem and what did you do to get it to work upto 16meg?

2. How is the flash allocation table set, with the division between code and application, where is the split to external flash ( i.e 1mg internal flash code, 1 meg internal flash application - xx meg application - or is the split internal flash just code and config and application is in external.

3. If the flash allocation is set as just internal flash, say < 1meg config and code and the remainder up to 2meg set to application, does the test application deploy and then the debugger connect - i.e is the problem when you get to external flash or is it when flash exceeds 4 meg - or is in the application dll size being too large for a single dll? Also is there a difference with a smaller flash allocation table ( just internal) on M7 and M4

4. when you had the flash allocation table set to >4Meg and had the deploy from VS problem - after deploy, does the application run and the problem is just VS Debugger doesn't connect - but deploy of application was fine, and after a reset the application runs. If application runs, if there are debug.print statements in the code, can you connect with MFDeploy and see the debug statements - i.e is the problem in the MF flash allocation handling or is it a limitation in the VS Debug handling?

Lastly, a comment on the M7 cache settings. We also found significant speed improvement by turning on the L1 instruction cache, but if you turn on the ram cache it will cause problems with the dma buffers for USB ( and any other dma use). The ram cache needs more work on the MMU, you need to allocate sections for the dma buffers and set the cache function of for these regions - we have not got round to this yet.
Lastly - in reply to your question why MF 4.3 - customer request, it was an upgrade to their M4 system and all their applications are on MF4.3 and they want to limit their production testing to just the differences between m4 and M7. When they are happy this is stable they may move onto MF4.4 and production test this, but they currently consider MF4.4 as 'un proven' from a test prospective.

Regards Sytech

[weixiongmei]

@SytechDesigns

1. It's the problem with the MF Deploy Tool on the PC side, I just set it to 8MB so i can use the code in the future hardware without any modifications.
2. Here is my Flash Map:
   0 0x08000000 0x00018000 Bootstrap
   1 0x08018000 0x00008000 Configuration
   2 0x08020000 0x00020000 Code
   3 0x08040000 0x000c0000 Code
   4 0x90000000 0x00800000 Deployment
3. Currently if the Deployment section is smaller than 16MB, it can runs without any problem, it's just the limitation regarding to the MF Deploy Tool on the PC side. But the .Net MF 4.4 has so many bugs. Such as, the VS Debugger only works randomly(No matter i compile the original M4 source to runs on the F407 or F429, it always happened, Press the F5 for debugging 10 times maybe can only get the debugger connected properly for just once, if the connection failed, i have to reset the board manually, it only has problem with debugging, deploying always succeed.)

The L1 instrution & data cache seems like working fine on my end so far, can get the L1 & DMA working at the same time. I'm still doing the stability tests on it to make sure there's no problem at all with both DMA & L1 enabled.
The firmware is running with an animation testing application without any issues for couple days, so i guess the L1 is just fine right now. (Before, the animation application will make the firmware flys in an hour with L1 enabled.)

[weixiongmei]

            OutputPort _OutputPort_LED = new OutputPort((Cpu.Pin)0x81, false);

            while (true)
            {
                DateTime _DateTime_Start = DateTime.Now;

                for (int i = 0; i < 100000; i++)
                {
                    _OutputPort_LED.Write(true);
                    _OutputPort_LED.Write(false);
                }

                DateTime _DateTime_End = DateTime.Now;

                text.Dispatcher.BeginInvoke(new DispatcherOperationCallback(args => 
                {
                    text.TextContent = "Time:" + ((_DateTime_End - _DateTime_Start).Ticks / TimeSpan.TicksPerMillisecond).ToString();
                    return null;
                }), null);
             }

Running this code only takes around 800ms on the STM32F746 discovery. Hope on the STM32H7 can get this done in about 200 - 300ms....

[SytechDesigns]

@weixiongmei
Hi , I've been a bit tied up lately...
Ok, just to confirm... the deployment error is occurring in the VS debugger/deploy engine, not in the MF4.4 port code.
You said you fixed it so it works with >4MB flash allocation, but must be < 16MB.

What exactly was the problem and what did you do to the deploy engine code to fix it?
There is currently someone working on the updated 'addon' for VS2017 - so now would be the time to get any fix in place, but they need a bit more info to see what the problem is and what you changed.

Is it a physical check on flash size, or is it anything to do with the USB protocol timing out, due to the time it is taking to erase the entire deployment allocated blocks?

Any chance you could publish your M7 and M0 ports - even if they are works in progress?

Regards

[doingnz]

As an aside comment regarding the time it takes to erase flash, I have found it is necessary to implement a check in the firmware if a flash block is not erased in code before issuing erase commands to the flash device. It is significantly faster to do a programmatic blank check and skip the erase if already blank, than have the flash hardware erase an already blank section. At-least that is my experience with Intel style Boot Block Flash with large blocks.