• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 52 subscribers
  • Views 1640 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Gui Composer over UART in F28335

Steve McDonald
Intellectual 475 points

Hello,

I am having some issues with Gui Compser and the UART routine that you guys provided in your demo code. Some time ago I had some issues getting the demo working with the F28335 and CCS V6 and you helped me to get it working, the problem back then was a bug in the CCS end I think where the F28335.GEL file needed to be cleared. Further to that I developed a prototype display module that I wanted to use within my own code.  This was tested and found to work fine with the shell code that was really doing nothing other than running the UART code that you provided. i.e it worked ok with either the JTAG interface or the UART.

I continued to develop my code and testing the interface using the JTAG for simplicity. However, the intention was to use the UART when operating the kit on power as the JTAG does seem to be a bit susceptible to locking up and once it has done so you can't regain control.

Ok, so some months later, now that I have built up my code to a point where I want to use the UART in anger and I can't get it to work at all. Clearly with the code in place and the PWM interrupts etc running the cycle time of the main loop is much longer (circa 2ms) so the code dealing with the characters will be running a bit slower, but I would have hoped it would be sufficiently robust to cope with this.

I have done some tests on the demo code you provided to replicate this slowing by putting timer delays in the "receivedDataCommand(getReceivedChar())"

routine  and the " __interrupt void sciaRxFifoIsr(void)"  function and it does seem to cope fine until the delays become really large. So I'm not convinced that the delay in the main loop is the source of my issues.

On probing further, I can see that the interrupt routine is definitely being triggered by setting a break there, I don't think there is a baud rate mismatch, but I am struggling to see where the problem lies. It may be something to do with the various other interrupts I have in place causing some kind of delay in the SCIA interrupt from being serviced, but this is speculation at this point.

I'm using CCS 6.1.0.00104, the F28335 and Windows 7 64 bit service pack 1

The non functioning code and GUI is attached, any suggestions would be welcomed.

files.zip

  • 0
    Intellectual 475 points

    Just to verify I went back to retest the latest version of my GUI display with the original part developed version of code and it is working fine either through the JTAG or via the com port. The only functionality is the comms healthy LED that flashes approx. 1per sec. See attached files

    SFiles 2.zip

  • 0
    TI__Guru**** 173310 points

    Steve,

    Sorry about the delayed reply to this post. I tried loading your code to the F28335 experimenter's kit but couldn't get it to halt at main and I don't think it is running correctly. If you are using a custom board, perhaps there is some specific initialization that is not suitable for this experimenters kit. I'm not quite sure where to go from here.

    You say the JTAG version works but not the UART. What exactly is the symptom? Are there any errors or the GUI just does not update?
    Are you testing this from within CCS or standalone GUI Composer Runtime?

  • 0 in reply to AartiG
    Intellectual 475 points
    Hello AartiG,
    I thought I had replied to your questions the same day as you posted them and was wondering how things were getting along, however, I don't see that post on here? I can only assume some web nonsense occurred with my phone.

    What I said was that the platform I'm using is the EZDSP not the experimenters kit. The first program uses the external ram on the EZDSP, perhaps that is your issue? Not sure, I assume you would spot that if it were the case. Both programs load and run fine for me so I'm really not sure what might be stopping them. The Gui works fine with the second program. but just doesn't seem to do anything for quite a while and then the time times out error kicks in after a time (from memory as its a while since I looked at it). I'm just picking up the problem again now after travelling a bit so any intput/suggestions would be welcome.
    regards
    steve
  • 0 in reply to AartiG
    Intellectual 475 points

    Hello Aartig,

    Further to yesterday's note, I have today been pulling apart my program to try and understand why this won't work. In doing so I have come unstuck with another problem that makes no sense. Attached are two test files, Display test and Display test v2 both of which I'm sure previously worked fine.

    The Display test is basically the TI demo code and Display test v2 has some timing delay functions added in in to experiment with delays etc in the comms. For testing I am adding a UART in CCS as per the demo instructions and monitoring a variable (Errorcount) in the watch window either via the JTAG or the UART as required. 

    Now here is the problem. Both programs will load and run quite happily if the CCXML file is configured without a UART connection. However, when I add the UART connection only the Display test will work. i.e the program loads via the JTAG, I start it and then load the symbols and can then view the watched variable from the UART connection in CCS.   Dislpay test V2 seems to try and load the .out file via the UART port rather than the JTAG interface when I click the debug button and CCS naturally throws up an error. I have tried to find a cause for this behaviour but so far am at a loss......

    regards

    steve

    display tests.zip 

  • 0 in reply to Steve McDonald
    TI__Guru**** 173310 points

    Steve McDonald said:
    However, when I add the UART connection only the Display test will work. i.e the program loads via the JTAG, I start it and then load the symbols and can then view the watched variable from the UART connection in CCS.   Dislpay test V2 seems to try and load the .out file via the UART port rather than the JTAG interface when I click the debug button and CCS naturally throws up an error.

    I don't see anything odd that explains why this works with one program and not the other, especially since both target configuration files are exactly the same. Was there a change in version of CCS or any other component between working and non-working versions?

    A couple of things to try:

    1) Instead of using the Debug button to debug Display test V2 , launch the debugger manually, then establish the connection to the C28x, select C28x device and use menu Load Program to load program, then select UART and use menu Load Symbols to load symbols.

    2) Try the troubleshooting suggestions mentioned here, specifically items 3, 4 and 5.

  • 0 in reply to AartiG
    Intellectual 475 points

    Hello AartiG,

    Ok, so your suggestions certainly helped me to get the little test programs running. I still have no idea why the loading defaulted to the UART, but it is quite easy to work around with the manual load as you suggested. It is possible I didn't check the correct boxes when I created the code. Anyway, both examples now work ok with the comms through the UART although there is a peculiar process whereby you initially load and run the code over the JTAG, verify all is ok then switch over to the UART, load the symbols and you usually get a comms error message from CCS. However, on further investigation it has actually loaded the symbols and is running ok. If you select the JTAG and then go back to the UART the watch window becomes active. This may well have sent me off on a goose chase a few times! 

    By the way, the delay timer settings in the DISPLAY test v2 are set too high in the version I sent you and the comms won't work as is. The CpuTimer0Regs.TPRH.all = 0x00ff; needs to be set down to 0x00 initially and then you can increase it as needed.

    Finally, I copied the test code over to a new version 3 and it all behaves as it should, i.e no need for manual loading which indicates something specific is afoot with V2.

    Now I do still have a real problem understanding why I can't get the bigger program (the stuff I sent first )working. I can understand why it might falter from my experiments with Display test v2 whereby increasing the time delay in the main loop will cause it to fail eventually. The version I sent you originally has a function in the main loop that periodically calculates a load of RMS values from an array and when doing so takes around 40ms to do its stuff. That said, when I disable that particular function the main loop seems to be cycling every 80us or so  it should be more than happy running the comms to via the UART, but as yet I have not succeeded in getting it to play ball when this function is disabled. 

    The only thing I can think of at present is that there may some kind of interrupt clash going on, but tracking it down is proving difficult.code with RMS function disabled.zip

    Attached is a revised version I have been testing with the RMS function disabled if you fancy having a peek?

    regards

    Steve

      

     

     

     

  • 0 in reply to Steve McDonald
    Intellectual 475 points
    P.S. I tried the GUI webapp with the code in the previous post and it does seem to have a go at working. Some of the icons change from crosses to live figures and it hangs in for a while before throwing its hands in the air. I increased the baud rate to 19200 and things didn't change a lot. You can see the RxD and TXD leds lighting on the USB com interface box. So it is trying......