• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 333 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1294NCPDT: TinyUSB

Sergio Caprile
Prodigy 70 points
Part Number: TM4C1294NCPDT


Anyone has made TM4C1294 or 129E work with TinyUSB ?
I get assertions with request type = 255.
https://github.com/hathach/tinyusb/discussions/1813

  • 0
    TI__Guru*** 135355 points

    Hello Sergio,

    We have not tried to implement TinyUSB on TM4C devices and I am not familiar with TinyUSB. Looking at the thread a couple comments I can make:

    1) The NDA process to get the USB datasheet is just a web form, follow the link on the device datasheet and review the document, I don't imagine you'll have a concern with what the agreement requests and then you can get full access.

    2) There are differences between the device families as far as clocking is concerned. You can review TivaWare examples for USB for both TM4C123 and TM4C129 and see if any of the APIs that TinyUSB uses needs to be updated.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 70 points

    Hi, I've already gone inside libraries through several layers of function calls grasping pieces of information, can you suggest examples as close to bare metal as possible ?
    My current controller initialization code is the following:

      // Configure B0 B1 L6 L7 as "analog": gpio->DIR bit input, ->AFSEL bit reset, ->AMSEL bit set
  SYSCTL->SRUSB |= BIT(0);               // Reset peripheral
  SYSCTL->SRUSB &= ~BIT(0);
  SYSCTL->RCGCUSB |= BIT(0);              // Enable USB clock
  volatile uint32_t *SYSCTL_RCC2 = ((volatile uint32_t *)SYSCTL) + (0x70/sizeof(uint32_t));
  *SYSCTL_RCC2 &= ~BIT(14);     // Enable nonexistent USB PLL / undocumented PHY clock
  USB0->CC = 0x207;               // Enable clock and configure divisor for 60MHz clock 
  USB0->GPCS = 3; // (41C) = 3
  USB0->LPMCNTRL &= ~BIT(0);  //(362) : reset bit0
  USB0->LPMCNTRL = 0; // (362) = 0
  if (USB0->EPCISC & BIT(0)) USB0->EPCISC |= BIT(0); // read EPCISC, check PF (power fault) flag, (40C) lsrs #1, and clear PF interrupt if so (write 1 to this bit)
  volatile uint32_t *USB0_IDVISC = ((volatile uint32_t *)USB0) + (0x44C/sizeof(uint32_t));
  if (*USB0_IDVISC & BIT(0)) *USB0_IDVISC |= BIT(0); // read nonexistent IDVISC, check IDVRIS_ID flag, (44C) lsrs #1, and clear condition if so (write 1)

    The processor is initialized to 120MHz

  • 0 in reply to Sergio Caprile
    TI__Guru*** 135355 points

    Hello Sergio,

    We do not support direct register programming models like you've posted for TM4C devices.

    If you want to get down to that level of detail, you can review the 'guts' of the TivaWare functions that handle the configurations to see how the registers are manipulated.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 70 points

    I've already done that, hence why I'm asking here...

    It is interesting to know that a hardware manufacturer does not support register level access of its hardware. Thanks anyway for answering.

  • 0 in reply to Sergio Caprile
    TI__Guru*** 135355 points

    Hello Sergio,

    We spent significant resources developing the TivaWare driver libraries and USB libraries in order to streamline and simplify the use of our TM4C devices. Aside from the rare occasions where hardware-level access is needed for performance purposes to minimize overhead, our long-standing guidance has been to use TivaWare APIs which are long proven to be stable and reliable. The stance to not support register level access stems from that we would be spending resources to effectively support re-designing the existing APIs from scratch all over again.

    Best Regards,

    Ralph Jacobi