NXP emWin library broken with apps running from external SPIFI or SDRAM...

[lpcware]

Content originally posted in LPCWare by achieveforce on Tue Oct 14 11:26:33 MST 2014
The following issues found are based on a design using LPC1788 with external SDRAM on the EMC bus. It has an RTOS resides in the internal Flash, while the emWin application runs from the external SDRAM. The emWin application is built as an re-locatable ELF binary.

(1) In the situation of running emWin application from external SDRAM (address starting at 0xA0000000) or SPIFI in LPC4088 case, emWin calls the RTOS functions (such as memcpy) which reside in the internal flash memory (address starting at 0). The function calls fail. It seems that emWin pre-built library is not built with -mlong-calls. We have confirmed that JMP24 is observed.

The use of external SPIFI or SDRAM to run apps is quite common in many applications. If anyone hits this scenario, the emWin library is broken in that sense.

(2) A less serious issue is the -fno-common is not in building the emWin library either. It is a fact that not all RTOS or maybe some flavors of embedded Linux support common section.

Your prompt response will be really appreciated.

Thanks.

[lpcware]

Content originally posted in LPCWare by achieveforce on Fri Oct 17 07:15:50 MST 2014
(1) The design we have is totally within NXP LPC1788/4088 specs. Running emWin app from SPIFI (which is a nice unique NXP innovation) separately from RTOS in internal flash should be something NXP encourages. It might be different from the "usual" cases you see here, but it is definitely not something unusual. We found it is quite common among the engineers in this section of application, because it provides extra security for the RTOS kernel and the flexibility of the application programs.

(2) Not every product development has the budget for a full source code licensing. One of the criteria to choose LPC for this product is that it provides free emWin GUI library.

Except that the NXP license with Segger does not permit making multiple builds of the emWin library, why can't NXP release another configuration of the emWin library for the users with long call requirements? A little extra work can retain some NXP customers. I won't think it is a bad thing. Certainly it is NXP's decision, but, in this competitive MCU market, quite a few chip manufacturers provide RTOS, GUI pre-licensed with their MCUs and try to support as many application scenarios as possible.

Don't get me wrong. I like NXP's MCU designs. NXP is pretty innovative in many areas of the MCU design. As a NXP customer, we feed back, you guys decide.

[lpcware]

Content originally posted in LPCWare by NXP_Support on Wed Oct 15 08:54:00 MST 2014
Hi achieveforce,

Thank you for your interest in NXP MCUs!  I'm sorry you are having difficulty with the emWin library we provide to our customers.  The emWin library is built to best meet the needs of the majority of our customers who build their application along with the library and execute them on any NXP MCU, working in space and performance constrained systems.  Your request is a more specific case which would have a negative effect on the majority of typical emWin library users.

Using long call
=============
With the long call option enabled, GCC loads the address of the function to be called into a register and then performs the function call on that register [otherwise the call is just performed directly on the address].  This process slightly increases both the size of the generated image and the execution time for all users on every call.  Our experience is that the great majority of our users do not need long calls and benefit from the smaller size and faster execution. 

COMMON Section
================
Most users do not need to worry about the common section as the linker scripts will place them in the .bss section.

NXP strives to provide useful software resources for our customers.  Unfortunately your request falls outside of the most common use cases for emWin and has some negative impacts for highly constrained systems.  Please consider licensing the emWin source code from Segger so you can build the code with the options you need.

Best regards,
-NXP Support

[lpcware]

Content originally posted in LPCWare by achieveforce on Tue Oct 14 20:36:40 MST 2014
Thanks for your reply.

However, I don't think running emWin app from SPIFI or SDRAM and calling RTOS functions in internal flash is such a special case as you described. I am sorry but your system is not set up that way does not mean it is so special. Only based on the postings here, I am afraid that you just can't make the exclusive conclusion what kind of setups are usual and what not.

No offense, but I am not sure if you fully understand the issue and what leads you to further make the judgment that this application scenario is out of the scope of the free version of the emWin library. I did read some reports that some people had the problem that when they move the emWin app into a different memory area (like SDRAM or SPIFI Flash), all of sudden it stops working. It is possible that they are using some sort of RTOS or some flavors of embedded Linux that is not statically linked to the emWin application and encountered the same issue here.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Tue Oct 14 14:13:05 MST 2014
Nxp's emWin is a free version of a commercial package. I don't think you can expect NXP or Segger to provide a free library that caters for every individual case or requirement. In my experience, the free library meets my requirements, and based on reports in this forum, seems to meet the majority of othe people's requirements too.

It seems that your circumstances fall outside of the domain of the free version, so I suggest that you buy the commercial license from Segger, which gives you source code, so you can build it yourself.