Requests


This page is for you! If you’d like more information about something I’ve posted about, or if there is a topic you think I should post about, please leave a comment and I’ll get right to it (as fast as my schedule permits it)!

I have started to list things in my bucket list (still ongoing).

For feature requests or bug reports on the McuOnEclipse project end Processor Expert components, you should use the GitHub issue tracking system:

Advertisements

899 thoughts on “Requests

  1. Eric,

    I have followed your guide for porting PEx to MCUXpresso as shown here: https://mcuoneclipse.com/2018/07/27/porting-processor-expert-projects-to-mcuxpresso-ide/

    I’ve tried multiple times, however, I keep running into an error something to do with the vector files. The error it describes is, “undefined reference to `__thumb_startup’ within the vectors.o resource. I am using the MK22FN256LVH12. Not quite sure why it would not be defined since when I search for its source it goes to this.

    #elif defined(__GNUC__)
    #ifdef __cplusplus
    extern “C” void __thumb_startup( void );
    #else
    extern void __thumb_startup( void );
    #endif

    Thoughts?

    Like

    • Hi Chris,
      you might have a look at https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/MCUXpresso/tinyK22/tinyK22_RoomMonitor as a reference.

      It looks like you still have __thumb_startup in Vectors_Config.h?

      ‘undefined reference’ means that the function is not defined (implemented) anywhere.
      Check that the ‘startup/startup*.c’ file is indeed compiled and linked. The entry point of the reset vector with the SDK is ResetISR() inside that startup file.
      Now the _thumb_startup() one is the startup name for KDS and usually referenced from the vectors file.
      You need to change the ‘Static_code\System\Vectors.c’ (which it seems you have found). A few lines below there is
      VECTOR_1, /* 0x01 ivINT_Initial_Program_Counter */
      which means you need to change the definition of VECTOR_1which is in Generated_Code\Vectors_Config.h

      /* Vector Address No. Pri Name Description */
      #if 0 /* original Processor Expert code */
      #define VECTOR_SP_MAIN &__SP_INIT /* 0x00 – ivINT_Initial_Stack_Pointer used by PE */
      #define VECTOR_1 (tIsrFunc)&__thumb_startup /* 0x01 – ivINT_Initial_Program_Counter used by PE */
      #else /* needed by SDK startup */
      #define VECTOR_SP_MAIN &_vStackTop /* 0x00 – ivINT_Initial_Stack_Pointer used by PE */
      #define VECTOR_1 (tIsrFunc)&ResetISR /* 0x01 – ivINT_Initial_Program_Counter used by PE */
      #endif

      I hope this helps?
      Erich

      Like

  2. Erich, Your posts are always the most helpful in filling the gaps between the theory and practice! Thank you for that. I would love if you covered the topic of end-user OS updating in the field. It looks like there may be two existing options for the IMXRT: MCUBoot/Flashloader or OpenSDA/DAP-Link (which requires a co-processor?)

    Thanks!

    Like

    • The DAP-Link (or debug port) is more for debugging and development, but not for updating systems in the field. Sure you can use it for that as well, but this requires better trained operators. The bootloader/flashloader is more intended for such an update process if you have physical access to the system. Other ways are using a network link for this.

      Like

  3. Hi Erich
    I found your blog very useful. Thank you a lot to share your experiences.
    Now i would ask you for a suggestion, maybe you are interested in writing a tutorial too.
    I’m using an iMX RT1050 EVKB with MCUxpresso.
    Everything is fine, every SDK example works fine while I run it alone.
    I tried then to build up my own application, but the same is if i try to merge up two samples to have at the same time lcdif (Rocktech part) and lwip.
    It looks like i misconfigured something, it always crash in hardfault handler routine.

    I also followed your article https://mcuoneclipse.com/2018/08/12/tutorial-open-source-embedded-gui-library-littlevgl-with-i-mx-rt1050-evk/
    Very impressive library!
    Cause your code already include freeRTOS, I managed to add ethernet there. I configured pins, includes, preprocessor, etc but no way to see it works.
    Can you help me in some way?

    Best regards,

    -Francesco-

    Like

  4. Hi Erich

    First of all thanks for the interesting website so its been one of the most useful ones for someone like me getting familiar with the Kinetis stuff. I have to learn Kinetis as I am working with a KL27 based board.

    The frustration I am having with KSDK is that the documentation shows 2016 on the website but the actual API seems to have changed and the documentation feels very sparse like its geared to someone who knows the products historically unlike ST Micro which feels a lot easier to get going with or is this just me? An example of such a change is that the SDK function GPIO_SetPinsOutput() seems to have been renamed as GPIO_PortSet() in the latest SDK downloaded from the builder and I had to read the source to figure out why my code wasnt compiling from the KDSK API documentation

    I need to get the LPUART to work and in order to do that I am not sure what clock setting to use in the LPUART_Init() function call.

    This is mostly due to the fact that its taking a lot of reading getting my head around the clocking on the device, I am starting to understand it but its heavy going and quite honestly feels like too much detail has to be understood to use the peripheral drivers. I will give kudos to NXP on the config tool as its very helpful and espscially the clock diagram helps in understanding, albeit the tool cannot do peripherals for the KL27.

    Do you have any advice on clock setup. It would be great if you could do a mini tutorial on clocking architecture in the Kinetis devices. I have used the Config Tool with MCUExpresso and have tried setting the following:

    MCGPCLK as IRC48M
    MCGIRCLK is 8Mhz

    so Core and System clocks are 48Mhzand the Bus and Flash clocks are 24Mhz and OSCERCLK and ERCLK32K as well as RTC_CLKOUT are all disabled.(all setup by the clock_config files exported from the Config Tools)

    I then call LPUART_Init() with a clock value of 8000000U and call the LPUART_EnableTx() in my main() program enter a loop and try sending a byte out continously without any activity on the other side.

    Do you have any advice?

    Like

    • Hi Peter,
      thanks, and you raise several good points and challenges I’m facing too. As for the ‘documentation’ I’m basically stick to the sources. I know it is not ideal. The thing with the GPIO_SetPinsOutput() and GPIO_PortSet() has hit me too. I have now a define in my library for the SDK version used (see https://github.com/ErichStyger/McuOnEclipseLibrary and the recent post https://mcuoneclipse.com/2019/01/27/tutorial-hd44780-display-driver-with-nxp-mcuxpresso-sdk/ where I use that library). Using that library I can keep some kind of thin abstraction layer between the SDK and the application. Best of all: I can mix and match the SDK with the NXP Processor Expert and MCUXpresso Configuration Tools :-).
      On the clocking: the Clocks Tool definitely helps, but one still has to read all the reference manual information. What I found it easier to use and understand is Processor Expert (but this is not supported for KL27). So I use it PEx for KL25Z or KL26Z and from this I apply my clock settings to the KL27Z. I have a few KL27Z boards around, but I have not used the KL27Z in an active project mainly because lack of Processor Expert support and limited RAM amount on the device (the K22F is right now what we are using a lot, but that’s a much larger MCU (and has PEx support)). Writing a tutorial for KL27Z certainly is technically doable, it is just that spare time is very limited, and I’m already struggling with getting all the material ready for the next semester…

      Like

  5. Possibly this is OT for ‘Requests’ but I respect the knowledge-base here on MCUonEclipse so I hope some advice is available.
    I’m looking for a good combination of ARM micro plus a Wifi connection. This is for a datalogging application. On the micro side I will collect data at a low rate for days or weeks, and use an SD card for storage.
    There are a number of simple Wifi solutions but all seems to use a UART or SPI connections to communicate with the host micro. I am looking for as fast as possible download, and these connections would represent a bottleneck.
    Is anyone aware of a simple Wifi solution that offers a faster connection? Many ARM micros offer a USB host or Ethernet peripherals these days, if there is something compatible with these it would be great to know about.
    Thanks, Ian

    Like

    • Hi Ian,
      I don’t think this is not OT (Off-Topic) at all.
      I have to say that all my WiFi ‘attached to micrcontroller’ projects have used UART and SPI.
      I started playing with ESP32, but not to a solid state yet. If you are not aware of ESP32, you might have a look into that device.
      You get WiFi with a microcontroller in one package. I don’t think that attaching this to USB/Ethernet ist probably not a good way.
      But just in case, as a ‘big’ solution: why not using a Raspberry Pi 3 Model B+ or similar? You get Quad Core ARM Cortex-A with SD card and WiFi 🙂

      Like

      • Thanks Erich,
        For reliability & robustness reasons I want to acquire the data using a micro (bare metal / RTOS) rather than a Linux device. The Wifi element is a convenience for the user – should the Wifi fail the logger data can be recovered manually by opening the sealed case and extracting the SD card.
        The Raspberry B+ is too big but I have seriously considered a ZeroW. Two concerns: 1) how to interface to the micro using a faster method than UART / SPI and 2) how robust these Linux devices are to power supply shutdown without corrupting their Linux install.
        Regarding ESP32 there seem to be a vast number of different carrier boards and modules available. So many that it’s hard to know where to start, and how long they’ll be around for… Maybe I just need to forget about longevity of supply and jump into some R&D…
        Thanks, Ian

        Like

  6. A quick general C question that I can’t find an answer for on the interwebs.
    I have a trace function which is basically printf with a bitmask:
    traceWrite(u32 conditionMask, char* str) {if (condition(conditionMask) printf(str);}
    There is also one for variable length:
    traceWriteF(u32 conditionMask, char* format, …) {if (condition(conditionMask) variadicstuff…;}
    But I hate having to have 2 functions, one for single, one for formatted. Does anyone know the trick to combine each of these? Somehow printf magically manages it, not sure if it’s a ‘special’ or not.
    Grateful for any help. Thanks 🙂

    Like

      • Yeah the format version of traceWrite, traceWriteF, uses varargs. I suppose what I want is to be able to do as printf does:
        printf(“a string”);
        printf(“show me %s”, theString);
        Somehow even though it uses varargs too, it deals with the single param case. My code throws an error if I use traceWriteF with a single string param.

        UPDATE: I’ve just tried compiling this again (it’s been years since I mucked with it) and now it seems to work. I don’t know what changed; perhaps a warning level?
        Looks like there is no problem after all. I’m so sorry to have wasted your time. Thanks for the response though.
        😦
        (runs and hides in cupboard…)

        Like

        • Happens to me too :-).
          One note: it is very important to include the header file for interfaces, especially for interfaces with open argument lists.
          Not following that is bad and can lead to strange things.

          Like

        • Absolutely. I elevate all warnings to errors (-Werror) which seems to enable implicit-function-declaration errors, among other things (is that what you meant?). I’d rather fight with a slightly pedantic compiler than have sloppy code come back and bite be later on.

          Like

  7. Erich,
    I’d like to get your opinion on a new problem that cropped up.
    I’ve been using the MK40DN512Z CPU for several years with Processor Expert.
    Now, NXP is discontinuing this version of the CPU and replacing it with MK40DN512.
    The old chip had Mask 4N30D and the new chip has Mask 5N22D.
    My existing code fails with the new chip (HARD FAULT) in cpu.c on the instruction that checks the mask.
    I’ve checked the Errata documents for both parts and there don’t appear to be any reasons that I cannot interchange them.
    Is there a Processor Expert solution to accepting either Mask?
    If not, how do you recommend modifying the PEx-generated code to make this work with both chips?
    Thanks,
    Greg

    Like

    • Hi Greg,
      I quickly created a project for the K40dN512Z, and I don’t see code in the CPU.c checking the CPU mask version? Did I miss it?
      I have not used the K40 for a long time: I used it at the beginning where the silicon had several issues. I was dealing with this with disabling code generation.
      So you could disable the code say for the cpu component and make your modifications as needed, and they don’t get overwritten.
      Have a look in https://mcuoneclipse.com/2012/03/23/disable-my-code-generation/

      I hope this helps,
      Erich

      Like

      • Erich,
        I thought you might enjoy what I found.
        The different mask value had nothing to do with the Hard Fault.
        Rather, CPU.c sets the RESET pin filtering values in SIM_SOUT6 for the MK40DN512ZVLL10.
        There is NO SIM_SOUT6 register in the MK40DN512VLL10.
        Thus the Hard Fault when accessing it.
        The wisdom of that change escapes me.
        Greg

        Like

        • Interesting, thanks for reporting back. I guess this is because that silicon was one of the very first and they seem to have changed that?

          Like

    • Hi Greg,
      I have not made a formal comparison. But CMSIS-RTOS is a wrapper or common API to different RTOS, and this only makes sense if I would like to use different RTOS (FreeRTOS, RTX, etc) in my applications (which I don’t intend to do). So from a user perspective it does not make sense to me. And it adds more complexity and with the wrapper it hides things, potentially not using all features. So I prefer directly to use the FreeRTOS API.
      It *does* make sense for a middleware vendor (e.g. a vendor selling a USB stack), as with this the stack could use CMSIS-RTOS to make it generic. But typically the interfaces are very thin, so it makes sense for them to use directly the FreeRTOS API or provide generic hooks (as lwIP or FatFS does) and go with it.
      I have not seen any real adoption in the market of CMSIS-RTOS except from ARM directly, maybe I’m wrong?

      Erich

      Like

  8. Ich habe das Projekt “ESP Wetterstation mit Farb-TFT” von Squix.org nachgebaut. Nun würde ich es gerne in ein Gehäuse einbauen. Leider habe ich keinen 3D-Drucker.
    Auf der Suche nach einem Gehäuse habe ich eines von Ihnen gefunden:
    https://mcuoneclipse.com/2017/09/10/wifi-tft-touch-lcd-weather-station-with-esp8266/comment-page-1/?unapproved=154363&moderation-hash=c0c42f6e3da679ac368b63fcd4d8cba0#comment-154363

    Wo kann ich dieses bestellen? Es gefällt mir sehr gut.

    Like

  9. Vielen Dank für die schnelle Antwort.
    Damit ich einen Laser-Cut machen lassen kann, benötige ich doch sicherlich eine Datei mit den Druckvorlagen für das gewünschte Gehäuse. Gibt es für Ihr Gehäuse so eine Datei für den Laser-Cutter?

    Like

  10. Hi Eric
    I saw your comment on Rob’s Sand bot. So I followed your avatar and ended up here.
    Boy!! it looks like you are a raspberry pi pro.
    I am also busy with my sand table build. Made it through al the pitfalls because I am not a programmer but more a handy builder. Ever since I saw the sisyphus it was a dream to own one. But as you know they are soooooo expensive. Are you planning to change the software or maybe port the code to a raspberry pi? That Would be great update. Rob’s software UI is OK but not very user friendly.
    I am busy making the actual table part now with a diameter of 1200mm. Electronics and mechanics is done and working. I used larger hybrid steppers and drivers for my table. Little more expensive but very quiet. Well worth the extra.

    Like

    • Glad to see you have found me :-). I’m actually not planning to use a Raspberry Pi, but instead a ARM Cortex-M4F microcontroller. I was inspired by the Sisyphus too, and first I was considering a XY solutionn. Digging more into the topic and because I plan a round table, I found Rob’s sand bot which works in a similar way as the Sisyphus. What Hyrid steppers are you using? I just ordered normal ones, and I hope the enclosure will keep it quit.
      I plan to use Sandify (https://github.com/jeffeb3/sandify) for pattern generation.

      Like

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.