• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 521 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.

MSP430F5529 USB Base Address problem

Khoa Mai Tan
Prodigy 20 points

Hi all ,

First, I'm sorry for my bad English. I am learning to implement  USBTMC class into MSP .My problem is that I don't know how to set base address to an endpoint ( actually I'm confused) , in USER GUIDE, They say that i can write upper 8 bits of the base address in to USBOEPBBAX_n, 3 LSB are set to zero as default , for total of 11bit. But, I've found that base address of the 1st USB's memory is 0x1C00 and it ends at 0x236F ( in binary : 0001 1100 0000 0000 and 0010 0011 1100 1111 and i think that i need at least  11bit  if ignored 3 LSB ???

Second, I want to access data from that address, i'm trying to use pointer point to that address, is that ok ? I've never accessed MCU's memory before. 

Last, I wonder why do all example code for USB API stack , TI uses forever loop while(1) to check USB status,  there are many interrupt events for USB module .why don't they use that ?

Best regard,

Thank you!!!

  • 0
    Guru 227245 points

    If I understood right, the 'address' used by USB hardware is relative to buffer memory. For the USB controller, the buffer starts at 0x0000 and ends at 0x07ff. 11Bit range.
    For the MSP, the buffer memory is memory mapped to a different location, not starting at 0x0000.
    Imagiene the buffer being a large array of char, located at the memory-mapped position inside MSP memory range. And the USB hardwares address is the index into this array.
    The base address is always aligned to an 8 byte boundary.
    And yes, you can us a pointer. On teh MCu side, teh buffer memory is just normal ram inside its address range. And if you don't use the USB controller, you can instruct the linker to add it to the ram segment, giving you 2k more for your application data.

  • 0 in reply to Jens-Michael Gross
    Prodigy 20 points

    I'm grateful for your help, it means that USB Engine will use the offset address to access data , but the pointer have to use MSP USB RAM's address to point to that value,
    But the last problem, can you tell me the diffrence between using foreverloop and USB_ISR.

    Thank you again

  • 0 in reply to Khoa Mai Tan
    Guru 227245 points

    Yes, that's how I think it works, based on the USB module description in the users guide. Chapter 40.2.4.3 tells that the memory is multiport memory, so USB and CPU cna address it independently, using their own memory bus each. Given the fact that the USB side pointers are 11 bit, it leaves no othe rway of interpretation than that everything that is related to the USB is a 0-based offset while the access from MSP CPU side requires adding the STABUFF start address, as shown in Table 40-3.

    Khoa Mai Tan said:
    can you tell me the diffrence between using foreverloop and USB_ISR.

    I'm not sure what exactly you mean.
    The USB ISR is called (providing that interrupts are enabled by setting GIE bit and the appropriate IE bits) when an event happens. And only then. The main code do es nto need to check or even care for it. It is interrupted where it is when an event happens. So you can do other things in the meantime.

    Using a 'forever loop' only, means that you have to constantly check the event flags and act when you detect that one happened.

    If you don't have to do anything else whiel waiting for the USB, there is not much of a difference. The only difference is that you can put the CPU to slwwp, saving some power. But sinse you most likely are connected to USBPWR, this is not really necessary.

    So on the bottom line, the only situation I can think of where it makes a difference is when you are not connected and are waitinf for plug-in. HTen not running the CPU in clircles all the time,but setting it to sleep until an interrupt comes, is likely the better option.

**Attention** This is a public forum