TMS570LS31x Dev kit serial port not working?

Tonyo,

If you haven't moved any jumpers on your development kit, the UART data should be sent to the FTDI chip that is also used for the XDS100v2 emulator.  If you have this hooked up to your PC you can find the COM port number that's associated with it, and try opening a terminal program.

Also, I believe the SCI/LIN module is used here - since it is the module that is wired to the FTDI chip.  It's pins are A7/B7 not W3/N2 which are to the plain 'SCI' module.  

I haven't moved any jumpers.

I see a blinking LED near the SCIRX and SCITX LEDs, but they do not blink.

If I start up TeraTerm and connect to COM port 17, set it for 9600 baud (or anything else for that matter), I see no text.

If I hit the ENTER key, the SCRX led flashes briefly.

If I scope A7 or B7, all I see is a 3.2 to 3.4V DC level.

Ok so sounds like some progress then.  I assume when you hit the "ENTER" key this is on the PC side so it would make sense that you're seeing the RX LED flashing as data is sent down to the board.  And that also sounds like it's a good sign that you are on the correct COM port...

There are some manual steps that you need to do other than just copy the example file over sys_main.  I have seen people miss these before so next question I think is to confirm you went through the steps in the help before generating code.

For example, in the help it shows some settings you need to do:

If you haven't gone through these yet - that is what I would try next.

well, this is not making any sense to me -

I got the example going by using the TI Resource Explorer->Hercules Tools->Devices->TMS570LS31x/21x->Examples.

I don't see anything like the above there. 

Tonyo,

Ok, thanks. The same demo is available through HalCoGen, but now I understand you are getting to it through CCS.

I'll take a look at the CCS demo and get back to you.

Tonyo,

I tried the demo from the CCS TI Resource explorer and I'm not getting any output either.

Do you see that the program reaches main() after you load the program?

If so when you run the program and then halt it, are you getting stuck in the same place that I am below?

yes, it looks like 

while ((sci->FLR & 0x4) == 4); /* wait until sci is ready */

is never exiting.

yes that's what I see.   Bit 2 (value of '4') is the IDLE bit not the TXRDY bit, I think it should be testing against bit 8 or a value of 0x10.

I'll check the HalCoGen version of the example to see if this is different.

EDIT:  The above was wrong.  The test for TXRDY is done at a lower level.  The test of the IDLE should be OK if the RX pin is high (and the RX pin is configured as functional, SCI is released from RESET, and the other necessary conditions for RX that are listed in the TRM chapter).  But mainly the test of IDLE should pass the first time and you should drop into the loop testing TXRDY if this were working properly.

why are there different versions of the examples for the same board?

How do you know what to use and when? 

Quite frankly, I am not impressed with TI's efforts; it seems that they are making the learning curve steeper than it needs to be...

Tonyo,

It's the same example,  but it ships with CCS for a quick out of box and with HalCoGen slightly less-ready in order to walk you through the steps of how to use the HalCoGen tool. 

I think actually both are the same and both are polling 0x04 there in that loop;   then inside the sciSendByte() function TXDRY is being polled (it's 0x100 not 0x10 as I wrote earlier).

I'm not sure why this is stuck in polling the IDLE bit - if there is no activity coming from the host.  This will need some investigation w. a scope.   

I also changed the code to skip this step and didn't get anything out of the terminal, so I think this one is going to take some additional work ... I'll let you know what I find.

Sorry for the inconvenience - wish we could get you an answer faster.

Tonyo,

In my build of the CCS example, I'm seeing what appears to be a mixing of SCI modules.

The init code appears to be initializing the SCI module at base address 0xFFF7_E500 but the polling is done on the SCI/LIN module at 0xFFF7_E400. 

Not sure how these things got crossed.. maybe it was configured for a different kit.  I'll need to research that one.

But the fix would be to try the example through HalCoGen and make sure to configure the SCI2 module as the one that you initialize through the GUI.

Are you up for this or would you like me to build this and post?

thanks for your attention to this; regular work issues have come up so I have to table this for now.

Please post instructions on how to use HalCoGen to build the example and I will get back to it on Monday.

thanks,

tony o.

Hi Tony,

The easiest way to get this working I think is a quick & dirty approach.  I tried it and it worked ok because the code is polling and doesn't use ISRs.

You can simply edit the file 'sci.c' and in the function 'sciInit()' change every pointer from sciReg to scilinReg. (There's about 15 to change and only change them in the function sciInit()...

It will look like this:

Or, if you feel more comfortable doing it this way, here is my edited source:

4744.sci.c

Then running the code you can see the result in the terminal window at the bottom of the screenshot...

Now this approach is something you can do in a few minutes to just see that the example can work.

But the correct approach would be to generate the driver code again using HalCoGen.

If you haven't already installed HalCoGen then please do so.  You can find it in the Tools and Software Tab on our product page www.ti.com\hercules.   Select "Software" section and look for the heading "Hercules Peripheral Drivers Library".

Once you have HalCoGen installed you can launch it and bring up the Help -> Help Topics.  It should look like this:

There are very detailed step-by-step instructions in the help for this example.  The instructions are also repeated in the top of the source file, but the online help has pictures which I think will be very useful.

If you run into any trouble this is the place to post.

well, I now have some time to work on this again - I brought up halcogen 03.06.00, navigated to the example example_sci_uart_9600, followed the instructions, and made a directory called serial_test with some source in it.

some minor problems are that the the diagrams presented by halcogen are drawn on top of one another, making it hard to figure out what to select.

I left everything as-is (default) and used file->Generate Code to build the code.

I tried using CCS 'Import Existing Project', pointed it to the serial_test directory, but nothing happens. 

So after building something with halcogen, what is next?

The help file ends with creating a new project, but then how do I then compile the code, download, etc.? 

tonyo,

Hi,

I think the HalCoGen GUI is sensitive for some reason to the windows 'Display" size that is in Control Panel.

On win 7 I've got mine set to 100% and it works but I think 125 or 150% make HalCoGen look weird.  We have a similar problem running on linux - hope you're not doing that.

HalCoGen doesn't generate a CCS project for you unfortunately.   You create the CCS project through CCS and then generate the HalCoGen files into the project directory ... or vice-versa (create a CCS project in the folder where you have generated you HalCoGen files).

Please see this WIKI page: http://processors.wiki.ti.com/index.php/Creating_new_CCS_v5_Project_with_HALCoGen

following the above, I now have a main() thet looks like:

void main(void)
{
/* USER CODE BEGIN (3) */
/* USER CODE END */
}

/* USER CODE BEGIN (4) */
/* USER CODE END */

I see a lot of files in the source directory, isn't there supposed to be some kind of call to them in main()?

Also, how would anyone know to do all this short of asking support? Is it written down somehwere?

tonyo, if you have a file 'main.c' then I think you might have created an 'Empty Project (with main.c)' rather than a pure 'Empty Project'.

That's ok.  Just delete the main.c file.

HalCoGen Generates the main() function in sys_main.c in the source folder.  

But in this case you will write over that function with the code from the UART example,  which is a sort of 'filled out' version of sys_main.c() anyway.   Or you can start by modifying the 'empty' sys_main.c file to match the UART example file;  if you want to examine what's added before you try to build.   Either way would work.

The text I sent was from 'sys_main.c'.

What I would like is not not have to hack the thing into submission, but make it work the way it is supposed to.

tonyo,

good point.  I should have caught that with the usercode comments.

so then you need to make the 2nd step.

Since you are working with one of the examples that comes with HalCoGen there should be a step that tells you to overwrite sys_main.c with the example '.c' file.

What I was trying to explain before is that normally you would be at this point and now have to start adding your application code to HalCoGen's sys_main().     In the case of the examples the 'edited' sys_main.c that implements the application example ships with HalCoGen so you can just copy/paste it over the generated file.

Since the example.c  is originally the same file as sys_main.c (but with stuff added to implement the example) it's not so much a hack as a quick start for the example.

If you study this example.c you will see that the code was all added between the usercode comment pairs.   This is how you do it so that you can run the code through HalCoGen again.  Anything you put between the comment pairs stays there through successive generations.    You can keep this same strategy when you build your own application on top of HalCoGen.

hmm,  I see in the 'Problems' window over 100 errors of the type

#20 identifier "ADC1_BNDCR_CONFIGVALUE" is undefined adc.c /serial_test/source line 942 C/C++ Problem

Sounds like yoiu may have a problem in Step 3 of http://processors.wiki.ti.com/index.php/Creating_new_CCS_v5_Project_with_HALCoGen

The include directory that halcogen generates needs to be added to the project build settings;  so the compiler can know where the header files are.   This is normal.