• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 357 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.

MSP432E401Y: How to find where Interrupt code is located

Brad McMillan
Intellectual 620 points

Part Number: MSP432E401Y
Other Parts Discussed in Thread: MSP-EXP432E401Y,

Hi,

I'm using an MSP-EXP432E401Y development board with the out-of-box example and CCS to start writing code for an application that will primarily be written in assembly language. 

One of the first things I'm trying to do is to figure out where I can read characters that are received over the serial port.  If I use Debug in CCS I can trace the code after a character is received, but it starts looping and never gets to where it reads the character.  The only way I can see the character at all is to release Debug, but the fact that I released Debug means that I was never able to see where the character came in.

It looks like the character is being read by it's interrupt code and in order to see where the character is being read that's the code I should be debugging.  But I don't know where the interrupt code is located.

Can anyone tell me how to figure out the location of the interrupt code that is executed when a character come into the serial port?

Thank you in advance to anyone that can help me find this code.

Regards,

Brad McMillan

  • 0
    TI__Mastermind 29565 points

    Hey Brad, 

    The out of box example for the MSP432E401Y is a multi-threaded RTOS based ethernet example.  It's written with TI Drivers, which is part of a heavily abstracted Software Development Kit.  The actual UART interrupt and data is handled somewhere down in TI Drivers or possibly deeper, and then is serviced by one of the threads of the RTOS.  

    Trying to go from this example to assembly, is going from two absolute max extremes in terms of software complexity and abstraction.  The MSP432E4xx is a very powerful and complex device.  I would recommend against trying to program it in assembly.  

    What are you trying to build?  Why were you planning to use assembly?  

    Maybe we can find a better MCU to fit your application.  

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    Intellectual 620 points

    Hello JD,

    Thank you so much for responding.

    I was attracted to the MSP432E401Y because it has just about everything we need built into one IC. The MSP-EXP432E401Y development board was also available with plenty of support so it was an easy choice to make in order to get started.

    Our application is very simple so we don't need the benefits of a complex RTOS or even languages higher than assembly. First, we are reading a few digital and analog signals and then reporting these values when we receive a command just a few bytes long with a response that is also just a few bytes long. Then we also have a few relays that we control from the same set of commands. Direct assembly code can be more efficient for a simple application like this and it has already been written in x86 assembly so it will be relatively easy to translate into RISC once I understand the I/O requirements of the MSP432E401Y.

    I realize the out of box example is way too complex to be used as a basis for our final design. I was just using it as a starting point to learn how to communicate through the UARTS. In another E2E thread I learned about the ethernet_weather example (thank you, Chester Gillon) which does not use an OS. It also uses TCP/IP which we need. The only things I need to learn now is how to configure it with a static IP address and how to send and receive data over Ethernet once it is configured.

    I appreciate any help you can provide to get past these last couple of steps, or, I'm also open to looking at any other MCU you think might be a better fit for our application.

    Thanks again,
    Brad McMillan

    1/22/21:

    Hello JD,

    Since posting my last response I determined that ethernet_with_lwip is the example I should be using, not ethernet_weather. It also does not use an OS. I don't have any problem configuring ethernet_with_lwip with a static ip address, but I still need to learn how to send and receive small strings of data with it.

    Thanks,
    Brad