Can't build STM32Stamp from PK 4.3 RTM QFE1 - General Discussion - Netduino Forums
   
Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Can't build STM32Stamp from PK 4.3 RTM QFE1


  • Please log in to reply
16 replies to this topic

#1 Savvkin

Savvkin

    Member

  • Members
  • PipPip
  • 15 posts

Posted 01 May 2014 - 10:16 AM

Hi guys.

I have STM32F103RET6 based board and trying to build NET MF for that.

Since the PK4.3 contains solution for STM32Stamp (which is STM32F103RET6 too) I decided that building this one is a good starting point.

 

I tried to build STM32Stamp solution from Porting Kit 4.3 (RTM QFE1) with Visual Studio 2013 (v12) and Keil 5.10, but I'm stuck.

I've added %VS120COMNTOOLS% to setenv_base.cmd to support MSVS2013 and added Keil 5.10 paths to \tools\Targets\Microsoft.Spot.system.mdk.targets file:

<CC      Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.10'">"$(MDK_TOOL_PATH)\armcc\bin\armcc.exe"</CC>
<CPP     Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.10'">"$(MDK_TOOL_PATH)\armcc\bin\armcc.exe"</CPP>
<AS      Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.10'">"$(MDK_TOOL_PATH)\armcc\bin\armasm.exe"</AS>
<LINK    Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.10'">"$(MDK_TOOL_PATH)\armcc\bin\armlink.exe"</LINK>
<AR      Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.10'">"$(MDK_TOOL_PATH)\armcc\bin\armar.exe"</AR>
<FROMELF Condition="'$(COMPILER_TOOL_VERSION)'=='MDK5.10'">"$(MDK_TOOL_PATH)\armcc\bin\fromelf.exe"</FROMELF>

To build I run:

cd /D f:\MicroFrameworkPK_v4_3
setenv_vs.cmd 12
setenv_mdk.cmd 5.10 f:\Keil_v5\ARM
cd f:\MicroFrameworkPK_v4_3\Solutions\STM32Stamp
msbuild /t:rebuild /p:flavor=release;memory=flash >msbuild.log

But build fails:

f:\MicroFrameworkPK_v4_3\tools\targets\Microsoft.SPOT.System.MDK.targets(276,4): error MSB3073: The command ""f:\Keil_v5\ARM\armcc\bin\armcc.exe"  --cpp  --diag_suppress 2874,111,161,550,C3011 --diag_suppress 66,161,230,1293 --split_sections  -DMDK_V3_1 -DARM_V3_1 -If:\MicroFrameworkPK_v4_3\DeviceCode -If:\MicroFrameworkPK_v4_3\DeviceCode\pal\rtip -If:\MicroFrameworkPK_v4_3\DeviceCode\pal\rtip\rtpcore -If:\MicroFrameworkPK_v4_3\devicecode\pal\rtip\tinyclr --feedback f:\MicroFrameworkPK_v4_3\tools\make\Feedback\STM32Stamp_MDK5.10.feedback -DTINYCLR_ENABLE_SOURCELEVELDEBUGGING  -DCOMPILE_THUMB2  -DVERSION_MAJOR=4 -DVERSION_MINOR=3 -DVERSION_BUILD=1 -DVERSION_REVISION=0 -DOEMSYSTEMINFOSTRING="\"Copyright Oberon microsystems, Inc.\"" -DPLATFORM_ARM_STM32Stamp  -DTARGETLOCATION_FLASH  -DLITTLE_ENDIAN  -DPLATFORM_EMULATED_FLOATINGPOINT=1 -DPLATFORM_NO_CLR_TRACE=1 -DTINYCLR_NO_APPDOMAINS=1 -DTINYCLR_NO_IL_INLINE=1   --thumb --apcs=interwork   --fpu none  --cpu Cortex-M3 --littleend  --no_debug --dwarf2 --no_debug_macros -O2 --inline -Otime --no_autoinline   -DNDEBUG  -If:\Keil_v5\ARM\RV31\INC -If:\MicroFrameworkPK_v4_3\CLR\Libraries\CorLib -If:\MicroFrameworkPK_v4_3\DeviceCode\include -If:\MicroFrameworkPK_v4_3\DeviceCode\Cores\arm -If:\MicroFrameworkPK_v4_3\Support\Include   -If:\MicroFrameworkPK_v4_3\crypto\inc  -If:\MicroFrameworkPK_v4_3\CLR\Include -If:\MicroFrameworkPK_v4_3\CLR\Libraries\CorLib -If:\MicroFrameworkPK_v4_3\CLR\Libraries\SPOT -If:\MicroFrameworkPK_v4_3\CLR\Libraries\SPOT_Hardware -If:\MicroFrameworkPK_v4_3\CLR\Libraries\SPOT_Graphics -If:\MicroFrameworkPK_v4_3\CLR\Libraries\SPOT_Net -If:\MicroFrameworkPK_v4_3\CLR\Libraries\SPOT_Net_Security -If:\MicroFrameworkPK_v4_3\Solutions\STM32Stamp -If:\MicroFrameworkPK_v4_3\devicecode\Targets\Native\STM32 -If:\MicroFrameworkPK_v4_3\DeviceCode\Cores\arm -If:\MicroFrameworkPK_v4_3\DeviceCode\Cores\arm\Include -If:\MicroFrameworkPK_v4_3\DeviceCode -If:\MicroFrameworkPK_v4_3\DeviceCode\Include -If:\MicroFrameworkPK_v4_3\DeviceCode\Targets\Native\STM32\STM32Stamp -If:\MicroFrameworkPK_v4_3\Support\Include -If:\MicroFrameworkPK_v4_3\DeviceCode\include -If:\MicroFrameworkPK_v4_3\CLR\include -If:\MicroFrameworkPK_v4_3\Crypto\inc -If:\MicroFrameworkPK_v4_3\CLR\libraries\corlib -If:\MicroFrameworkPK_v4_3\BuildOutput\THUMB2\MDK5.10\le\ANY_MEDIA\release\lib    -o f:\MicroFrameworkPK_v4_3\BuildOutput\THUMB2\MDK5.10\le\ANY_MEDIA\release\obj\CLR\Libraries\CorLib\CorLib_fastcompile.obj -c f:\MicroFrameworkPK_v4_3\CLR\Libraries\CorLib\CorLib_fastcompile.cpp " exited with code 1. [f:\MicroFrameworkPK_v4_3\CLR\Libraries\CorLib\dotnetmf.proj]

This command throws 43 warnings and 6 errors like those:

"f:\MicroFrameworkPK_v4_3\CLR\Libraries\CorLib\corlib_native_System_BitConverter.cpp", line 99: Error:  #1151: floating-point variable definition with initialiser is not permitted with --fpu=none
float input = stack.Arg0().NumericByRefConst().r4;

"f:\MicroFrameworkPK_v4_3\CLR\Libraries\CorLib\corlib_native_System_BitConverter.cpp", line 199: Error:  #1265: converting to and from floating-point type is not permitted with --fpu=none
stack.SetResult_R8(*p);

 

Any ideas?



#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 01 May 2014 - 04:28 PM

Hi Savvkin,

The .NET MF 4.3.1 release added a new BitConverter class which wasn't designed to work with microcontrollers using some/all forms of emulated floating point.

If you'd like to compile your own firmware for non-Netduino targets, I'd recommend starting out with the 4.2 Platform Kit. Or use the 4.3.1 PK with Netduino overlay and compile for STM32F2/F4 targets.

Chris

#3 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 01 May 2014 - 04:45 PM

Attached is a zip archive with BitConverter source for 4.3 QFE1, which compiles fine in recent Keil MDK versions (5.x).

Attached Files



#4 Savvkin

Savvkin

    Member

  • Members
  • PipPip
  • 15 posts

Posted 01 May 2014 - 08:53 PM

Thanks. I was able to build STM32Stamp solution myself (while waiting post moderation :P ).

 

I used BitConverter from the latest netduino 4.3.1 and modifed paths for MSVS 2013 and Keil 5.x in setenv_base.cmd and Microsoft.Spot.system.mdk.targets.

Here is the zip containing diff vs official v.4.3.1: https://dl.dropboxus...12.MDK_v5.1.zip

 

But now I'm little confused. STM32Stamp solution doesn't have TinyBooter. Only TinyClr. I tried to flash tinyclr.bin\ER_FLASH at 0x08000000 using ST-Link, but seems it hangs on boot. I think I'm missing some very basic here. Maybe I should flash ER_CONFIG at 0x08000000 and ER_FLASH after that at some offset? :wacko:

 

I've noticed files like system_stm32f10x.h and stm32f10x.h in Netduino overlay. Does it mean I can use 4.3.1 PK with Netduino overlay to build for F1? Could you give some directions? :rolleyes:

 

Update:

Actully I found pdf from Oberon saying tinyclr.bin\ER_FLASH to 0x08000000 and tinyclr.bin\ER_CONFIG to 0x08040000, I tried, but board still doesn't show any life signs. So I'd really like to build TinyBooter for STM32F1.



#5 Savvkin

Savvkin

    Member

  • Members
  • PipPip
  • 15 posts

Posted 03 May 2014 - 05:19 PM

I'm stuck again :wacko:
Board still not recognized in Windows (Can't configure USB). Tried to flash my led blinky app (both .exe and .pe files) at 0x08042000, no luck.

Firmware stuck in the loop somewhere around CLR_RT_ExecutionEngine.DebuggerLoop or CLR_RT_ExecutionEngine.WaitForActivity (as least what I see when debugging in uVision with tinyclr.axf assembly).

No idea what's happening and what to do next. Anyone?



#6 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 03 May 2014 - 06:15 PM

Board still not recognized in Windows (Can't configure USB).

 

Have you switched/configured USB transport in your solution? Because STM32Stamp solution uses serial (COM1) by default, it will not be recognized as a USB device.



#7 Savvkin

Savvkin

    Member

  • Members
  • PipPip
  • 15 posts

Posted 04 May 2014 - 01:29 AM

I tried to replicate USB code from Solutions\MCBSTM32E, but not sure if it's done right.

Could you explain how to switch/configure USB in STM32Stamp solution?



#8 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 04 May 2014 - 11:11 AM

You can compare those two solutions to see what needs to be done:
  • Change the serial transport to USB in platform_selector.h - replace COM1 with USB1 in #define statements,
  • In TinyCLR.proj replace USB config library stub with the actual one, i.e. replace
    <RequiredProjects Include="$(SPOCLIENT)\DeviceCode\Drivers\Stubs\USB_Config\dotNetMF.proj"/>
    <DriverLibs Include="usb_pal_config_stub.$(LIB_EXT)"/>
    
    with
    <RequiredProjects Include="$(SPOCLIENT)\Solutions\MCBSTM32E\DeviceCode\USB\dotNetMF.proj"/>
    <DriverLibs Include="usb_pal_config_MCBSTM32E.$(LIB_EXT)"/>
    
    or path of your library copy,
  • Change USB VID and PID identifiers in usb_config.cpp to valid values, preferably something with already working .NET MF USB driver; otherwise you'd have to create new WinUSB driver installation (custom .inf).
I have not verified that, so there could be something missing. Also, it is likely the USB feature will require some additional flash space, so you'd probably need to adjust the memory layout in the scatterfile and blockrange configuration (g_STM32_BlockRange in STM32_BlConfig.cpp).

#9 Savvkin

Savvkin

    Member

  • Members
  • PipPip
  • 15 posts

Posted 04 May 2014 - 09:49 PM

Did all of this several times.

 

 - Replaced COM1 -> USB1 in platform_selector.h

 - TinyCLR.proj replace USB stub

 - Change VID and PID (wont help, since I don't see any USB activity)

 - If it compiles, does it mean no flash space in needed? I ask, because I had to change scatter/BlConfig to fit debug version (there was errors building debug)

 

No USB insertion detected.

For some reason, it stucks in Events_WaitForEvents loop forever.

 

\DeviceCode\pal\events\events.cpp:

UINT32 Events_WaitForEvents( UINT32 sleepLevel, UINT32 WakeupSystemEvents, UINT32 Timeout_Milliseconds )
{
    NATIVE_PROFILE_PAL_EVENTS();
    // do NOT call this routine with interrupts disabled,
    // as we can die here, since flags are only set in ISRs

Does this mean MCU interrupts are not initialized properly?



#10 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 05 May 2014 - 06:25 AM

Does this mean MCU interrupts are not initialized properly?

 

It's hard to say, but probably not - interrupts are used rather often, so it probably would not work at all if they were not initialized properly. I would focus on USB, maybe there is a problem during initialization. Personally, I would firstly verify the firmware actually works with the serial (COM1) transport, I am a little bit skeptical that these old solutions were tested with .NET MF 4.3+. Then, I would try to determine why the device does not enumerate, most likely using a USB protocol analyzer... Also, you said you had a custom board?



#11 Savvkin

Savvkin

    Member

  • Members
  • PipPip
  • 15 posts

Posted 05 May 2014 - 02:40 PM

How to do this (check debug initialization)? Keil doesn't let me step into the code, only into assembly.

If you are talking about software USB protocol analyzer, could you recommend one?

If DeviceCode\Targets\Native\STM32 code is not changed, why shouldn't it work in NET MF 4.3? Do you think I should try first with PK 4.2.0, 4.2.1 or 4.2.2?



#12 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 05 May 2014 - 03:46 PM

How to do this (check debug initialization)? Keil doesn't let me step into the code, only into assembly.

 

How are you using Keil debugger? You can create an empty project, set its output name to tinyclr, build output path to ...BuildOutput\...\bin (where tinyclr.axf is located) and the IDE should load debugging symbols automagically, letting you step through the code and place breakpoints...
 

If you are talking about software USB protocol analyzer, could you recommend one?

 

I use USBlyzer occasionally.
 

If DeviceCode\Targets\Native\STM32 code is not changed, why shouldn't it work in NET MF 4.3? Do you think I should try first with PK 4.2.0, 4.2.1 or 4.2.2?

 

Well, I don't know - I am not sure in what .NET MF version STM32Stamp solution was introduced, but there have been various changes in the .NET MF core code since then. But if you can get pass the initialization, then the problem is most likely in the USB, or memory layout (config sector could not be found?)... Really hard to say...



#13 Savvkin

Savvkin

    Member

  • Members
  • PipPip
  • 15 posts

Posted 05 May 2014 - 05:48 PM

Yes, I debug the way you describe, but only see Assembly window (see attachment) and View -> Source Browser Windows (is this one I need?) shows "No Browse Information available in ... Check - [Target-Options] [Output] [Browse Information]"

 

Do I need debug  (/p:flavor=debug) version? Is ST-LINK v1 enough or I need ST-LINK v2?

 

I tried 4.2.2 - same result.

Also, I've implemented TinyBooter in 4.3.1 for STM32Stamp - it dies at the same location, no USB connected.

 

Update:

Yes, adjusted scatter file (added more RAM) and rebuilt debug version of TinyBooter.

Now I can see both Symbols and Source and can step into the code. Now I just need to understand STM32 initialization code, because it's different from examples that Keil provide and STM32CubeMX codegen create.

Any useful code nav tricks here? Where can be most possible point of failure?

Attached Files



#14 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 06 May 2014 - 09:03 AM

Check - [Target-Options] [Output] [Browse Information]"
 
Do I need debug  (/p:flavor=debug) version? Is ST-LINK v1 enough or I need ST-LINK v2?

 
"Browse Information" checkbox works only when you generate the output from within Keil µVision IDE, it has no effect when you build the .axf file externally (i.e. .NET MF msbuild system). Also, I am not sure it is necessary, it should be enough to add debugging information to the .axf - it is done automatically in the 'debug' configuration, and I think debugging information is not present for 'release'.
 

Update:
Yes, adjusted scatter file (added more RAM) and rebuilt debug version of TinyBooter.
Now I can see both Symbols and Source and can step into the code. Now I just need to understand STM32 initialization code, because it's different from examples that Keil provide and STM32CubeMX codegen create.
Any useful code nav tricks here? Where can be most possible point of failure?

 

Although there are some differences, the initialization code in basically always the same: start at reset vector, init stack, perform C runtime init (zi, .bss), jump to entry point function, initialize hardware (clock, interrupts, peripherals etc.). I would have a look at USB initialization, perhaps also reading the config sector...



#15 Savvkin

Savvkin

    Member

  • Members
  • PipPip
  • 15 posts

Posted 06 May 2014 - 07:43 PM

Tinybooter doesn't depend on anything in flash to startup, so it doesn't need config sector, right? It uses UsbDefaultConfiguration from usb_config.cpp to setup USB.

 

I've tried step thru code, but don't see any obvious fails. All checks passes. It reports that USB initialized fine and interrupts activated. But nothing actually happens.

 

I've notices that this one inside tinyhal.cpp is skipped:

#if !defined(HAL_REDUCESIZE)
    CPU_InitializeCommunication();
#endif

I rebuilt without HAL_REDUCESIZE, but seems like it's just early duplicate initialization that gets overridden later at ApplicationEntryPoint in TinyBooter.cpp.

 

 

Anyway, main USB initialization code is at CPU_USB_Initialize in STM32_usb_functions.cpp, interesting line is:

HAL_Time_Sleep_MicroSeconds(1000); // asure host recognizes dettach/attach

According to comment, I expected that PC should beep here. But it's not. Something failed silently?

 

 

There are 3 defines: STM32_USB_Attach_Pin_High, STM32_USB_Attach_Pin_Low and STM32_USB_Attach_Pin_Direct.

Are they vital to start USB? I think they only need to show "USB is connected" to user code, so they can't cause problems and I can ignore them?

 

I didn't find any code that initializes PA12 (USB_DP) and PA11 (USB_DM) pins. Only reset code at IO_Init.cpp:

GPIOA->CRH = 0x44444444;

Reference say that no special initialization needed for USB pins, but internet recommends to set it explicitly to alternate function open-drain, like this

GPIOA->CRH = 0x444EE444;

So, probably I'm missing proper initialization code in IO_Init.cpp?



#16 Savvkin

Savvkin

    Member

  • Members
  • PipPip
  • 15 posts

Posted 06 May 2014 - 10:49 PM

Finally got USB up and running! Device recognized in MFDeploy

Pinging... TinyBooter

It was USB attach pin...

#define STM32_USB_Attach_Pin_High        (16 + 16 + 13) // PC13


#17 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 07 May 2014 - 06:23 AM

Congratulations!






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.