STM32F429-EVAL Porting Issue(s) #496
Comments
|
Have a look at the memory files here https://github.com/IngenuityMicro/NETMF-DISCO-429 |
|
Cool, thanks. Very much appreciated. |
|
Thanks for the help. My issue was that I was placing my CONFIG image on 2 different Storage devices. By the way there is a note in the xml scatterfile that states this requirement, that I some how overlooked. If it had been a snake, ... I am guessing that MFDeploy of the managed application and debugging VS2015 are related. Both procedures perform a reboot of the device as part of their process and then attempt to reconnect. It appears that this reconnect attempt is timing out. |
|
Yes, both VS and MFDeploy use the same underlying components to interact with the device. Do you have serial debug messages available? If so can you post them? That might help figure out where things are going wrong. |
|
I was able to get VS2015 debugging to work with my port of the STM32F29-EVAL board on a Win 10 64-bit PC, that was a clean install of VS2015. I still had an issue with MFDeploy deploying a managed application, "Error: Controller not started, cannot create message", same problem I have on the Win 7 32-bit machine. Here is serial debug messages from VS2015 Output: Micro Framework Device Deployment Output Window - Looking for a device on transport 'USB' Debug Output Window - The program '[5] Micro Framework application: Managed' has exited with code 0 (0x0). |
|
Every now and then debugging on the Win 7 32-bit machine works. I can not find a consistent method that triggers it to work. Tried erasing deployment, erasing and re-installing entire device, restarting VS2015 sometimes when I perform either of the above it will work. Sometimes if I just keep attempting to launch the debugger it will work after a few attempts. Here is a successful attempt debug messages (Debug Output window): Found debugger! Create TS. Loading start at 8120000, end 81343dc Assembly: mscorlib (4.4.0.0) Assembly: Microsoft.SPOT.Native (4.4.0.0) Assembly: Microsoft.SPOT.Hardware (4.4.0.0) Attaching deployed file. Assembly: Microsoft.SPOT.Graphics (4.4.0.0) Attaching deployed file. Assembly: MFConsoleApplication1 (1.0.0.0) Resolving. The debugging target runtime is loading the application assemblies and starting execution. 'Microsoft.SPOT.Debugger.CorDebug.14.dll' (Managed): Loaded 'C:\Program Files\Microsoft .NET Micro Framework\v4.4\Assemblies\le\Microsoft.SPOT.Native.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. |
|
I have tried reorganizing my memory map in various ways and always get the same end result. I setup to use only internal flash, duplicating the STM32F429-Discovery layout, same result. The NOR flash is a M29W128GL (@0x60000000), 128 uniform sectors of 128KB. One problem I had early on was I can't define all 128 sectors in BlockConfig, as MFDeploy calculates a timeout value based on the memory size but then checks this against a fixed max value (60 * 60 * 1000) when doing an EraseMemory function. So I just defined 64 sectors (8MB) of the 128. I also had a problem when I placed ER_CONFIG at 0x60000000 and ER_DAT at 0x60020000 MFDeploy would always start erasing at 0x60000000 when deploying ER_DAT after ER_CONFIG, and would erase ER_CONFIG. I put ER_DAT in the internal Flash 0x08120000, and that solved that. I didn't understand why though, as the MCBSTM32F400 example is configured similarly except the different sector sizes at the start of the NOR flash. I did not change the Flash driver code, as I did not see anything in the code that needed to differ for Uniform vs. Non-Uniform Flash sectors. My VS2015 debugging issue I can address with using another PC, the PC I am attempting to use has had just about every IDE and programming/debugging device installed at one time or another. The MFDeploy issue with deploying a managed application (.hex) is a concern. At production time it would be the tool to use to deploy the managed application to production boards. I don't have an MCBSTM32F400 board to test this. Is the MFDeploy tool able to Create Application Deployment file, and then Deploy that file successfully on the MCBSTM32F400 port? Thanks for the help. Sorry about so much info. Working hard at this, cause I have to make a decision on how to continue soon. I am developing a product for a customer. I ported micro framework V2.5, V4.1 to hardware with an IMX processor previously. |
|
I had a similar problem with "Attaching to device" on Windows 7 #250. I changed procedure CorDebugProcess.AttachToEngine. |
|
There is a registry entry that enables a longer timeout on the reboot. (I can't remember off the top of my head, I'll try and find it in the code) Ultimately that's something we should probably surface as a setting in the MFDeploy application and in the Visual Studio project extension so we don't rely on manual registry edits. |
|
kodfilemon Thanks for the information. Ultimately I was hoping for a solution where I didn't have to hack the RTW SDK. I figured I could do this to get MFDeploy working for my system. I didn't want to also have to maintain and distribute a release of the SDK to support end customers in addition to hardware port files. |
|
Please don't hack and release the SDK and MFDeploy, that just makes everything harder for everyone. The registry entry should suffice - though it's a lousy end user story to have to manually edit the registry. We should definitely address that by providing a clean UI in VS and MFDeploy |
|
Perhaps this one?
|
|
Yes, the timeout value in that key would be the one. Thanks for looking it up. For the future versions we should include UI in MFDeploy and the VS integration for adjusting this. (Or just suck it up and completely re-write the wire protocol libraries using modern async patterns... ) |
|
Update on my issue. I now have a clean install of Windows 10 64-bit desktop with VS2015 that I get the same error as my Win 7 32-bit desktop : I have a Laptop with Windows 10 32-bit with VS2015 and I can debug successfully. I tried the registry settings on both desktops. I found the .NETMicroFramework key in the LocalMachine keys and manually added "\NonVersionSpecific\Timing\AnyDevice" key and added the 3 DWORD values "override", "retries", and "timeout". I set the "override" value to 1, and "timeout" to 10000. Did not seem to affect my problem. One thing I noticed about this issue is that the error message comes back almost immediately when the VS2015 attempts to reboot the device. It is almost like it is not waiting or retrying any connection. The issue must be in my porting code, memory layout or drivers. I tried lots of variations here. Are there users using V4.4 and creating Managed Applications using VS2015 and MFDeploy tools successfully? Thing is that I am pretty much finished with porting to my hardware platform. To this point, using the Laptop mentioned previously, I was able to get the SD card, File System, wired Networking, LCD touchscreen, RTC, Flash and SDRAM working and proven out in Managed code. Trying to finalize my porting code and move onto the managed application. My CPU is a STM32F429 vs the STM32F407 I think the MCBSTM32F400 development board has on it. My external Flash device is a uniform sector device, 128 sectors of 64KB, M29W640GL70. In case this has any bearing. Does MFUpdate come into play here? Right now my TinyCLR project is using the MFUpdate stubs. Thanks for any help or input on this issue. |
|
If you run the debug build of MFDeploy you can enable the detailed protocol tracing. That can help narrow down what the problem is. The full tracing is only enabled when compiled with the TRACE flag, which ordinarily is only set for debug builds. However, basic tracing is available via ETW for all releases. The key difference is with tracing enabled the log is visible in an attached debugger and it includes names of packet commands instead of just the IDs. (See DebuggerEventSource.cs for more info.) There is also device side tracing available but that is really only useful if you have a JTAG debugger with support for ITM trace logging. |
|
@smaillet-ms I ran MFDeploy in the debugger as you suggested. Reference attached trace log file. AppDeploy_FailedAttempt_Log.txt After the Reboot command completes MFDeploy transmits an Execution_ChangeConditions flags[NoCaching] command and this results in System.InvalidOperationException being thrown. I tracked this exception down to the AsyncFileStream.cs file and the following code: SafeFileHandle handle = NativeMethods.CreateFile(file, NativeMethods.GENERIC_READ | NativeMethods.GENERIC_WRITE, share, NativeMethods.NULL, System.IO.FileMode.Open, NativeMethods.FILE_FLAG_OVERLAPPED, NativeMethods.NULL); From the Debugger Additional Info: If I put a break point on the throw new InvalidOperationException line and then continue the code, the deployment process will work and my deployed app runs. I think the above is related to why I am also having troubles debugging a managed application from VS2015 since it deploys and then does the reboot process. The above exceptions must get thrown after the reboot completes and causes the debugging process to fail. There is a System.ComponentModel.Win32Exception exception thrown before the InvalidOperationException. I don't know if that is the root of the issue I haven't tracked that down yet. Thanks for the help tracking this issue down. |
|
Interesting... That actually helps to explain things a bit. It looks like two different issues are going on. The device is completely taking down the USB connection on the reset command from the attached debugger - it isn't supposed to do that on deployment. It should only do that on a full reset for a firmware deploy. MFDeploy should be able to handle that but apparently isn't in this case. MFDeploy should be able to recover from this with a retry... Not sure why that isn't happening in this case. |
|
I think I tracked this issue down to ReceiveInput method in Controller.cs. The InvalidOperationException occurs when ReceiveInput method calls OpenPort(). There are a number of retries ( = 5). However these retries happen very quickly as the Thread.Yield() call in the exception handling routine does not provide any significant time delay. So the retries expire prior to the MF Device completing a reboot and the USB connection being ready. I increased the retries to 100, still not enough. I replaced Thread.Yield() with Thread.Sleep(1000) and retries = 10. This provided enough time for my MF Device to reboot and the USB communications to become available. Is this an indication that my porting code is taking to long to reboot? Thanks. |
|
It's a consequence of bad/ancient .NET 1.1 original design of the MFDeploy code plus differences in modern device hardware that have altered the timing to where this can hit. Injecting a thread sleep is always a bad idea. (In fact the Yield was introduced along with many others to dramatically improve the debug/deploy/step and watch window performance.) Retry counts are generally a dumb idea, in this case I think the quickest surgical strike solution is to fix this particular case so it is looking at total time waiting, that is the start time should be marked, then run a loop calling Thread.Yield the timeout period has expired. Ideally the whole thing needs a re-write to use modern async patterns with event triggers (e.g. await for device to disconnect, then await for device connect then send command xyz... with the whole thing being controlled by a cancelation token with a timeout on the complete operation.) |
|
@smaillet-ms Thanks for all your help to this point. I traced down where the USB Debugger port was getting reset to Messaging.cpp and the CLR_Messaging::CleanUp() method. There is a flag "g_fDoNotUninitializeDebuggerPort" that is assigned in Tinyhal.cpp. Initially in my porting code this flag was set to "false", I changed this to "true" and this prevents the USB debugger port from being uninitialized during MFDeploy and VS2015 Debugging/Deployment and this has resolved my Managed App Debugging and Deployment issues without needing to update Controller.cs. |
I have a STM32F429-EVAL board. I am currently working with the TINYCLR_NONET target as I attempt to get Microframework to work on this Eval board. Tinybooter running and mostly functioning NONET TinyCLR. I wanted to take advantage of the F429 2MB Flash and place Tinybooter, ER_CONFIG, ER_DAT, and ER_FLASH images within this space and preserve the NOR Flash for Deployment.
Memory Layout = TinyBooter-0x08000000, ER_FLASH-0x08010000, ER_CONFIG-0x08100000, ER_DAT-0x08110000 and Deployment starts at 0x60000000.
Development tools - Keil/ARM MDK 5.05 compiler, VS2015 Community Update 3 on Win7 32-bit.
My Issue starts when I attempt to load and debug the Hello World console app from VS2105. Every now and then (Usually the very first attempt) debugging works correctly, but mostly I get the "failed to (re)connect debugger engine to debugging target" error and then next attempt I will get the Deployment error popup and I can see the in the Debug Output console on VS2015 that my Hello World application ran. It seems to be some kind of timing issue with debugging.
The deployment works, I can see the data in the NOR Flash at 0x60000000 using the ST-LINK Utility.
MFDeploy issues that might help point me in the right direction. Since I deployed the Hello World in VS2015, successfully I think, when I attempt to Create Application Deployment from MFDeploy I get the "Device has old or unsupported configuration" message. I also see this message when attempting Configuration of Network settings.
FYI. I have had previous versions of Microframework on my development PC. Previously I was developing in NET MF V4.1 using VS2010 C# Express. I uninstalled NET MF V4.1. I once also had NET MF V4.3 installed when I was evaluating NET MF using an STM32F4-DISCOVERY board.
Any help is appreciated. I am developing new hardware based on the STM32F429 and would like to run NET MF if I can get it working and ported to my hardware design.
Thanks.
The text was updated successfully, but these errors were encountered: