dlbeer / mspdebug

Debugging tool for MSP430 MCUs
GNU General Public License v2.0
184 stars 80 forks source link

Simulating UART #83

Closed chrissphinx closed 5 years ago

chrissphinx commented 5 years ago

We are using this library by Stefan Wendler to give students an easy way to have a "command line like" experience when programming the MSP430.

However, for automated testing this poses a problem. It seems mspdebug sim can handle timers, gpio and interrupts caused by those pins no problem, but is there a way to simulate the UART interface so I would be able to connect to it using a program like minicom just as if it is programmed onto the actual board?

dlbeer commented 5 years ago

chrissphinx notifications@github.com writes:

We are using this library by Stefan Wendler to give students an easy way to have a "command line like" experience when programming the MSP430.

However, for automated testing this poses a problem. It seems mspdebug sim can handle timers, gpio and interrupts caused by those pins no problem, but is there a way to simulate the UART interface so I would be able to connect to it using a program like minicom just as if it is programmed onto the actual board?

The closest thing that currently exists is the "console" simio module, but this will only simulate transmission. I take it this isn't enough for what you're doing?

What you're describing could certainly be implemented as a new simio module though -- you could allocate a pseudo-tty under Linux or BSD and translate register access to reads and writes to the tty. Then you could spin up minicom or similar and talk to the pseudo-tty.

Cheers, Daniel

-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B

tgtakaoka commented 5 years ago

Having UART simio sounds great!

chrissphinx commented 5 years ago

@dlbeer thanks for the reply, Daniel, are you saying it will only simulate transmission from the msp430 to the host machine or from the host to the msp430?

dlbeer commented 5 years ago

chrissphinx notifications@github.com writes:

[1]@dlbeer thanks for the reply, Daniel, are you saying it will only simulate transmission from the msp430 to the host machine or from the host to the msp430?

Currently it only simulates transmission from the MSP430 to the host machine, and in a fairly simple way -- there's no virtual TTY or anything like that.

-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B

chrissphinx commented 5 years ago

Actually I think that would work for my needs because I could put a driver in front of code I want to test the simply sends characters to the host.

I assume that means I need to create a console peripheral that is "listening" at UCA0TXBUF (or 0x0067 for the MSP430G2553)?

EDIT:

So, this appears to be getting stuck as it's waiting for the UCA0TXIFG flag to be set (I think)

(mspdebug) run
Running. Press Ctrl+C to interrupt...
^C
    ( PC: 0c446)  ( R4: 00000)  ( R8: 00000)  (R12: 00000)
    ( SP: 003ea)  ( R5: 05aff)  ( R9: 00400)  (R13: 02580)
    ( SR: 00002)  ( R6: 00000)  (R10: 0c4d2)  (R14: 00000)
    ( R3: 00000)  ( R7: 00000)  (R11: 0c4c3)  (R15: 00048)
serial_send_blocking+0x4 (���������s):
    0c446: 2e f3                     AND     #0x0002, R14
    0c448: fc 27                     JZ      serial_send_blocking (blocking)
    0c44a: c2 4f 67 00               MOV.B   R15,    &0x0067
    0c44e: 30 41                     RET
serial_recv ():
    0c450: 5f 42 66 00               MOV.B   &0x0066, R15
    0c454: 30 41                     RET
(mspdebug) simio info txbuf
Base address:   0x0067
Buffer:
(mspdebug) dis serial_send_blocking
serial_send_blocking ():
    0c442: 5e 42 03 00               MOV.B   &0x0003, R14
    0c446: 2e f3                     AND     #0x0002, R14
    0c448: fc 27                     JZ      serial_send_blocking (blocking)
    0c44a: c2 4f 67 00               MOV.B   R15,    &0x0067
    0c44e: 30 41                     RET

You can see $r15 currently is holding 0x48 'H' because I'm trying to send "Hello, World!\n\r". It appears the memory address is never written though 😞

Is there a way to get the simulator to hold UCA0TXIFG set in IFG2 maybe?

dlbeer commented 5 years ago

chrissphinx notifications@github.com writes:

I assume that means I need to create a console peripheral that is "listening" at UCA0TXBUF (or 0x0067 for the MSP430G2553)?

Yes, that's correct. Any byte writes to the configured address will be printed on stdout.

Cheers, Daniel

-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B

chrissphinx commented 5 years ago

Sorry, Daniel, I had edited my previous reply. But, I actually got this to function by forcibly writing to IFG special function register:

(mspdebug) md 0x0003 1
    00003: 00                                              |.               |
(mspdebug) mw 0x0003 FF
(mspdebug) run
Running. Press Ctrl+C to interrupt...
Hello, World!
Hello, World!

Then no need to write to it after that? Any idea what's going on with this special function register in the simulator?

dlbeer commented 5 years ago

chrissphinx notifications@github.com writes:

Sorry, Daniel, I had edited my previous reply. But, I actually got this to function by forcibly writing to IFG special function register:

(mspdebug) md 0x0003 1
    00003: 00                                              |.               |
(mspdebug) mw 0x0003 FF
(mspdebug) run
Running. Press Ctrl+C to interrupt...
Hello, World!
Hello, World!

Then no need to write to it after that? Any idea what's going on with this special function register in the simulator?

It may be that your code is waiting for the TX ready flag to be set for the UART peripheral. That's not simulated, but manually setting the SFR byte to 0xff will make it appear set to the code if that's the case.

-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B

chrissphinx commented 5 years ago

Okay great, I think I have all that I need for the moment, then. Thank you for the help, Daniel!