none
Compact 2013: Functions in SRAM corrupt after suspend RRS feed

  • Question

  • This is a difficult one, but I thought I'd ask in case someone else has experienced this problem. I've been working on migrating our CE6 device to WEC2013. Our device uses a OMAP3703 processor. The BSP we downloaded for this processor copies certain power sensitive functions (such as suspend and resume) to SRAM. For some strange reason after our device has suspended these function(s) in SRAM become corrupt. After resuming from suspend if we call our suspend assembly function from SRAM 'OALCPUIdle' we get an error message "Faulted in KCall, PC = bb108199...". To workaround this problem we no longer call 'OALCPUIdle' from SRAM. However, I don't understand why this problem occurs.

    This problem hasn't occurred for us in either CE6 or WEC7. Has anyone experienced this problem before? Anybody have an idea why this happens?


    Any insight appreciated!

    Monday, December 19, 2016 4:09 PM

All replies

  • Are you absolutely sure the SRAM contents actually corrupt? Have you checked with a JTAG to see where the resume code resumes execution, whether this is in the correct place and whether SRAM contents are really not as you expect them to be?

    It could very well be a caching issue that just never reared its ugly head with the old ARM compiler. Connecting a JTAG will give you direct insight into these issues.


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: https://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    NXP Proven Partner
    https://guruce.com
    Consultancy, training and development services.

    Interested in WEC on i.MX6?
    Get the only 100% stable and best performing i.MX6 BSP for WEC7 and WEC2013 here: https://guruce.com/imx6

    Tuesday, December 20, 2016 1:06 AM
    Moderator
  • Thanks for the quick reply Michel. I'm not absolutely sure SRAM contents have become corrupt. I haven't needed to use JTAG before but perhaps that should be my next step. I just know from using the Visual Studio debugger that I get an error when calling the OALCPUIdle function. The address of the OALCPUIdle function is 0xbb108199 and the error message I get is 'Faulted in KCall, PC = bb108199'. Calling this same function isn't a problem before going to suspend; it's only a problem after resume. Thanks for the advice!
    Tuesday, December 20, 2016 3:48 PM
  • Quick question Michel - what about this problem made you suspect it's a caching issue? I ask this because I'm looking at something new and I get a similar but different error I can't explain "!FATAL ERROR!: Secure stack overflow ... Faulted in KCall, PC = 800b7e5f...". I've been developing in a Windows CE environment for a while but I've never seen these "Faulted in KCall" errors before. This new error has nothing to do with suspend/resume, but it did occur on WEC2013. If our WEC2013 device has a caching problem I obviously need to address it.

    Thursday, December 22, 2016 4:18 PM
  • what about this problem made you suspect it's a caching issue?

    Because most BSP developing companies get this wrong...

    The WEC2013 ARM compiler is now using Thumb2 and with this you will need to modify a lot of (especially low level) assembly code. Did you go through all of the assembly code and made sure you are adhering to Thumb2 rules?

    See https://msdn.microsoft.com/en-us/library/jj919375.aspx

    and https://www.e-consystems.com/blog/windowsce/?p=1333

    and https://www.e-consystems.com/Articles/Windows-CE/windows-embedded-compact-2013-thumb2.asp


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: https://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    NXP Proven Partner
    https://guruce.com
    Consultancy, training and development services.

    Interested in WEC on i.MX6?
    Get the only 100% stable and best performing i.MX6 BSP for WEC7 and WEC2013 here: https://guruce.com/imx6

    Thursday, December 22, 2016 7:51 PM
    Moderator