[SOLVED] embOS + embUSB-Device and Cortex M3 (LPC1768) is working GOOD!...

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] embOS + embUSB-Device and Cortex M3 (LPC1768) is working GOOD!...

    Hi, I am beginner. I`v downloaded SES 4.12. I have a trial licence.

    I`v compiled "SeggerEval_emPower_emUSBD_Audio_SES_180424" example good. This is Cortex-M4 controller.

    But I create new project with LPC1768 (Cortex-M3). I`v tried to compile for LPC1768 controller and I have received any errors :

    undefined reference to `OS_InitKern_STD'
    undefined reference to `OS_InitHW'
    undefined reference to `OS_CreateTask_DP'

    As I understood the difference in #define OS_CPU_HAS_VFP - (Floating Point)

    Can you recommend me anything?

    ---------------------------- The problem has resolved with Cortex-M3 (LPC 1768) ! ---------------------------------------

    I install the ESPRO package.

    I have used the RTOS.h from ......\SEGGER Embedded Studio\v3\packages\ESPRO\OS\Inc

    I have used the libraries from .....\SEGGER Embedded Studio\v3\packages\ESPRO\OS\Lib\:
    libos_v7m_t_le_dp.a - debug
    libos_v7m_t_le_r.a - release

    I have compiled my project normal.

    Embedded Studio is really good idea! Now will try USB-HID attached...

    Thank you for attention!

    The post was edited 4 times, last by kkmspb ().

  • [SOLVED] embOS and Cortex M3 (LPC1768) is possible to compile?

    Hello kkmspb,

    great to hear it's working now.

    Just as a clarification: We're renaming some API functions to prevent incompatible setups. "OS_CPU_HAS_VFP" depends on the architecture/core options passed to the compiler and renames the OS_InitKern() (OS_Init() in V5) function, while the OS_LIBMODE_* definitions rename the OS_CreateTask() (OS_TASK_Create() in V5) to ensure the compatibility to the linked embOS library. If no OS_LIBMODE_* definition is set by the user, OS_LIBMODE_DP will be used by default.

    Best regards,
  • Hi Michael!

    Thank you for your answer.

    I have launched next project with emOS normal.

    But I meet a problem with emUSB (on LPC1768) . I have spend two days with situation below:

    Source Code

    2. {
    3. BSP_ToggleLED(0);
    4. USB_OS_Delay(50);
    5. }
    When I turn on controller after USB-Start() USBD_GetState() returned 0x10 (=USB_STAT_ATTACHED)

    After 2-3 seconds USBD_GetState() returned 0x11 (=USB_STAT_ATTACHED&USB_STAT_SUSPENDED)

    When I connected USB cabel the USBD_GetState() returned also 0x11.

    This occured with examples : USB_HID_Keyboard.c , USB_CDC_Echo.c , USB_HID_Mouse.c ...

    USBLyzer and Control Panel Windows did not show any new device...

    I forget to add the USB log:
    0:000 MainTask - USBD_Start
    0:000 MainTask - *** Warning *** Bus RESET should not occur in unattached state!

    The post was edited 4 times, last by kkmspb: The problem is resolved! ().

  • The device does not seem to enumerate. Could you please set a breakpoint in the USB ISR routine and see if you arrive there when you connect the cable to your PC?

    I see that you have used an emPower project as a base, it will not work on the LPC1768 out of the box as it is a completely different MCU...
  • When I connect USB cabel I step here

    Source Code

    1. void USB_IRQHandler(void){
    2. OS_EnterInterrupt();
    3. if (_pfUSB_ISRHandler) {
    4. _pfUSB_ISRHandler(); // here step occured
    5. }
    6. OS_LeaveInterrupt();
    7. }
    I suppose that maybe:
    1. I have downloaded at first emPower example with MK66 (HS USB) and changed it to LPC1768(FS USB).
    2. I am disturbed about USB frequency settings.

    Do you recommend me some example for like LPC1768 controller with emOS and emUSB-Device? I searched it at forum and downloaded area but I not found anything.
  • Yes - the problem was resolved during 3 days!

    Bus RESET should not occur in unattached state! - This is important message that i get on any examples permanently with my LPC1768 board.

    This board is from old receipt printer. This is not evaluation board.

    And USB D+ must be pull-up to 3.3V by 1.5K resistor. This is assigned to Host that the Device have FULL Speed Rate.

    I.E. this was not software problem - this was the hardware mistake.

    Thank all!
  • I 'v tried to compile the USB_HID_Keyboard.c example from ...SEGGER\SEGGER Embedded Studio\v3\packages\ESPRO\USBD\Application

    and Release Version is working good (symbols is sended normal to PC to Text Editor), but in Debug version its does not send to PC.

    In Debug Mode by JLink debugger the controller stop here:

    Source Code

    2. {
    3. BSP_ToggleLED(0);
    4. USB_OS_Delay(50);
    5. }
    6. // USB_STAT_CONFIGURED is not occures

    As I have understood the controller run to OS_Error(OS_STATUS ErrCode) with OS_ERR_SYS_STACK and hang here :

    Source Code

    1. void OS_Error(OS_STATUS ErrCode)
    2. {
    3. OS_EnterRegion(); // Avoid further task switches
    4. OS_DICnt = 0u; // Allow interrupts so we can communicate with embOSView
    5. OS_EI();
    6. OS_Status = ErrCode;
    7. while (OS_Status) { // !!!!!!! here
    8. // Endless loop may be left by setting OS_Status to 0
    9. }
    10. }
    I suppose "OS_LIBMODE_DP" needs lib not libusbd_v7m_t_le_d.a but libusbd_v7m_t_le_dp.a ?

    Source Code

    1. #if DEBUG
    2. #define OS_LIBMODE_DP
    3. #else
    4. #define OS_LIBMODE_R
    5. #define OS_VIEW_IFSELECT OS_VIEW_DISABLED // embOSView communication is disabled per default in release configuration
    6. #endif
    Or maybe you recommend me any something?
    • 2019-04-12_11-09-57.png

      92.88 kB, 1,680×895, viewed 613 times

    The post was edited 4 times, last by kkmspb: continue... ().

  • Hello kkmspb,

    OS_ERR_SYS_STACK indicates an overflow of the System Stack. Can you increase the stack size and repeat your test? Does the issue persist?

    The reason the application "works" in release is that embOS will not perform stack checking in release configurations. Thus it will not call OS_Error(). But the stack could still have overflown in release as well, which may still result in a faulty application. Hence, we typically advise to develop in debug configurations and move to release only after the debug configuration was proven to work correctly.

    kkmspb wrote:

    I suppose "OS_LIBMODE_DP" needs lib not libusbd_v7m_t_le_d.a but libusbd_v7m_t_le_dp.a ?
    I'm not sure whether I understand this question correctly. The OS_LIBMODE_* define is relevant to embOS only, while the cited libraries seem to be USB libraries. There's no dependency between those.

    Best regards,
  • Hello kkmspb,

    It seems you're increasing the stack size for one task. However, you'd need to increase the System Stack size instead. This can be done in the project options under "Code -> Runtime Memory Area -> Main Stack Size".

    Best regards,