12 thoughts on “McuOnEclipse Components: 8-May-2016 Release”

1. Hi Erich

   Great like always!
   I use utility module from your components (not exactly version from this post)

   ** Processor : MKE02Z64VLH4
   ** Component : Utility
   ** Version : Component 01.117, Driver 01.00, CPU db: 3.00.000

   End I think found a bug:

   this code will not work
   uint8_t buf[5];
   uint8_t buf[0] = ‘1’;
   UTIL_PE_strcatNum16Hex(buf + num, 5U, 0x1234);

   this will:
   uint8_t buf[5];
   uint8_t buf[0] = ‘\0’;
   UTIL_PE_strcatNum16Hex(buf + num, 5U, 0x1234);

   I have debug and I think error is in: UTIL_PE_strcat().

   Best Regards
   /Greg

   LikeLike

   Reply ↓

   • Hi Greg,
     the first pointer to strcatNum16Hex() and all the other functions point to the start of the buffer, and the second one to the total size of the buffer.
     I’m not sure about your second code snippet (copy-paste error).
     But you need to call it like
     UTIL_PE_strcatNum16Hex(buf + num, sizeof(buf)-num, 0x1234);
     means you need to adjust the size of the buffer if you are passing a pointer inside the buffer.
     I hope this makes sense?
     Erich

     LikeLike

     Reply ↓

     • num is copy/past error, just assume num is 0. always point to first element of buffer.
       problem is in UTIL_PE_strcat() caleld at the and of strcatNum16Hex:
       why, this method looking end of string? (dst != ‘\0’) in first while? that’s why second snippet works…

       void UTIL_PE_strcat(uint8_t *dst, size_t dstSize, const unsigned char *src)
       {
       dstSize–; /* for zero uint8_t */
       /* point to the end of the source */
       while (dstSize > 0 && *dst != ‘\0’) {
       dst++;
       dstSize–;
       }
       /* copy the src in the destination */
       while (dstSize > 0 && *src != ‘\0’) {
       *dst++ = *src++;
       dstSize–;
       }
       /* terminate the string */
       *dst = ‘\0’;
       }

       LikeLike

       Reply ↓

   • Hi Greg,
     All the utility ‘cat’ functions expect a valid buffer, zero terminated.
     With that buf[0] = ‘1’;
     you do not have valid buffer any more, so you need to add
     buf[1] = ‘\0”;
     too.

     I hope that makes sense,
     Erich

     LikeLike

     Reply ↓

2. Erich:

   much more sense now.
   I did not notice such assumptions. documentation is:
   /*!
   \brief Adds a 16bit number as hex value to a string.
   \param[in,out] dst Start of buffer, where to append the number string
   \param[in] dstSize The size of the buffer, including the zero uint8_t
   \param[in] num The 16bit number to add
   */

   buffers are not the same concept as strings… do not have to be ‘zero terminated’. misleading.
   Now understand. thanks!

   LikeLike

   Reply ↓

   • I see now where the disconnect is. I have updated the comments/documenation to make it clear now: https://github.com/ErichStyger/McuOnEclipse_PEx/commit/5661e299a92540153fe648e16d977148a4d7491a
     Thanks for bringing this up!

     LikeLike

     Reply ↓

3. Hi Erich,

   First I want to thank you for your work, I am a big fan of your processor expert components.
   I am using it since yeas now. For my current project I am using a K22 MCU with KDS, PE and your FRTOS and USB CDC components. Everything worked fine till 7.Feb.16 release. Today I updated to 8.May release and I got problems: Application running as normal, but as soon as the first data is sent via USB the Application hangs in vPortEnterCritical.

   Also tried the 3.Apr release and same behavior. Going back to 7.Feb fixed the problem again. So my question, did you tried the combination FRTOS + USB CDC with the new releases? Just want to know if is is a bug in component, incompatibility or just a bug on my side.

   please keep on the good and helpful work,
   best wishes,
   Hans

   LikeLike

   Reply ↓

   • Hi Hans,
     let me check this today and report back to you. Not sure what is happening here….
     Erich

     LikeLike

     Reply ↓

   • Hi Hans,
     I checked the USB CDC again with a FreeRTOS project on a K64F, and that works fine. Any information you could provide about the problem you see? You can send me that as well to the email address listed on the About page (https://mcuoneclipse.com/about/).
     Thanks,
     Erich

     LikeLike

     Reply ↓

4. Erich:

   Using the 2016-06-25 beans, FreeRTOS and TMOUT.

   Events.c has the following:
   void FRTOS1_vApplicationTickHook(void)
   {
   /* Called for every RTOS tick. */
   /* Write your code here … */
   TMOUT1_AddTick();
   }

   So, when FreeRTOS ticks, it will increment the timeout and everything is good, right? Nope.

   TMOU1_Addtick calls CS1_EnterCritical, which navigates through the macros to FreeRTOS vPortEnterCritical, where it subsequently hangs in the configASSERT that checks if it’s being called from an ISR. In previous version(s) of the beans, this assert did not exist in vPortEnterCritical.

   I can obviously fix the issue by either writing my own critical section handler, or setting CS1 to not use FreeRTOS. Neither of those is particularly appealing.

   I’m happy to make a patch, but I wanted to get your thoughts on the best way to handle this. The CS bean is obviously is used from interrupts and needs to be safe working that way.

   Sean

   LikeLike

   Reply ↓

   • Hi Sean,
     Indeed, this is a problem :-(. You could disable the ‘use FreeRTOS’ setting in the CS1/CriticalSection component (this is what I have typically).
     The correct way would be to have this:
     
#define CS1_EnterCritical() \
taskENTER_CRITICAL_FROM_ISR() /* FreeRTOS critical section inside interrupt */
#define CS1_ExitCritical() \
taskEXIT_CRITICAL_FROM_ISR(0) /* FreeRTOS critical section inside interrupt */

     I have commited a fix on GitHub, so this will be available in the next version:
     https://github.com/ErichStyger/McuOnEclipse_PEx/commit/5d0420782a21eee3bee8b7484fc38d30b8e3e5bb

     The fix is rather easy, so you could apply it in your component sources as well. Let me know if you need assistance on this.

     I’m sorry for the problem, I hope this helps you,
     Erich

     PS: you could submit bug reports as well in GitHub (https://github.com/ErichStyger/McuOnEclipse_PEx/issues)

     LikeLike

     Reply ↓

     • Ahh, yes, that’s the right fix. I kept looking for a vPortEnterCritical_FromISR and was determined there wasn’t one.

       taskENTER_CRITICAL_FROM_ISR() does the trick, thanks!

       Sean

       LikeLike

       Reply ↓

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