RTOS/TMS320F28375D: Migration of existing project into a new SYSBIOS/XDC version

Lenio Cacula

Part Number: TMS320F28375D
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

When migrating an existing C2000 project to SYSBIOS 6.73.01.01 / XDC 3.50.08.24, the compiler flags hundreds of errors about missing files, functions with the wrong number of arguments, and unresolved symbols. What is the best practice when migrating to a new RTOS version? Should we start a new project with SYSBIOS and import the files into it (this would be troublesome for this particular application, since it has many files)? What are the alternatives?

Thank you!

over 7 years ago

0 ToddMullanix over 7 years ago

TI__Guru* 96960 points

Hi Lenio,

You should just be able to change the products versions being used (i.e. SYS/BIOS and XDCtools). I'd check the release notes in 6.73 to see if you need to change compiler versions also and any other breaks in compatibility. What versions of XDCtools and SYS/BIOS are you migrating from?

Todd

0 Lenio Cacula over 7 years ago in reply to ToddMullanix

TI__Genius 17100 points

The customer is on XDC version 3.24.6.3 and SYS/BIOS 6.35.4.50.

0 ToddMullanix over 7 years ago in reply to Lenio Cacula

TI__Guru* 96960 points

Lenio,

That's a larger jump, but should work. What compiler version are you using? The 6.35 BIOS used the C28 6.1.0 compiler and BIOS 6.73 uses 16.9.1 one.

Todd

0 Jason Enyart over 7 years ago in reply to ToddMullanix

Intellectual 605 points

Hello folks. Compiler version is 6.2.11.

0 Lenio Cacula over 7 years ago in reply to ToddMullanix

TI__Genius 17100 points

The compiler version is 6.2.11

0 ToddMullanix over 7 years ago in reply to Lenio Cacula

TI__Guru* 96960 points

I know there where some changes made to the compilers, can you try using 16.9.1? If that works, I'd probably recommend using v16.9.9.LTS or the maybe even v18.1.4.LTS.

0 Jason Enyart over 7 years ago in reply to ToddMullanix

Intellectual 605 points

I see 16.9.1.LTS here: www.ti.com/.../16.9.1.LTS

Is that the version you want me to try? I noticed that the installer no longer seems to target c:\ti.

Also, I seem to have 16.9.3.LTS installed. Will that work for these purposes?

0 ToddMullanix over 7 years ago in reply to Jason Enyart

TI__Guru* 96960 points

Hi Jason,

16.9.3.LTS should be fine.

Todd

0 ToddMullanix over 7 years ago in reply to ToddMullanix

TI__Guru* 96960 points

Did the 16.9.3.LTS compiler resolve the issue?

0 Jason Enyart over 7 years ago in reply to ToddMullanix

Intellectual 605 points

Sorry, we had to put this on hold in order to meet our sprint objectives due this week. I will be looking into this some more starting on Wednesday at the earliest, Possibly as late as Monday. I will report back in with you. Thanks!

0 ToddMullanix over 7 years ago in reply to Jason Enyart

TI__Guru* 96960 points

No problem. Fingers crossed:)

0 ToddMullanix over 7 years ago in reply to ToddMullanix

TI__Guru* 96960 points

Any updates?

0 Jason Enyart over 7 years ago in reply to ToddMullanix

Intellectual 605 points

Customer preferred that we just configure the ISR outside of BIOS rather than upgrade it at this time. Lenio had provided this link with instructions: http://processors.wiki.ti.com/index.php/SYS/BIOS_for_the_28x?keyMatch=rtos%20high%20priority%20interrupt&tisearch=Search-EN#Minimal_Latency_Interrupts I plugged the ISR directly into the vector and the issue seems to no longer occur.

I would like to follow up with a question about these bullets from that wiki page:

"To consolidate code that performs register saving and restoration for each interrupt, SYS/BIOS provides an interrupt dispatcher that automatically performs these actions for an interrupt routine. Use of the Hwi dispatcher allows ISR functions to be written in C. In addition to preserving the interrupted thread's context, the SYS/BIOS Hwi dispatcher orchestrates the following actions:

Disables SYS/BIOS Swi and Task scheduling during interrupt processing
Automatically manages nested interrupts on a per-interrupt basis.
Invokes any configured "begin" Hwi Hook functions.
Runs the Hwi function.
Invokes any configured "end" Hwi Hook functions.
Invokes Swi and Task schedulers after interrupt processing to perform any Swi and Task operations resulting from actions within the Hwi function.

By default, all Hwi interrupts created statically or dynamically with SYS/BIOS are routed to the interrupt dispatcher."

Other than use of the interrupt keyword, are there any other safeguards that need to be put in place for the management functions described as being normally performed by the dispatcher? The buffer management scheme is safe but just wanting to checking because the PDF linked in that section warns about using this method only when necessary.

Thanks.

0 ToddMullanix over 7 years ago in reply to Jason Enyart

TI__Guru* 96960 points

The key point with zero latency interrupts is not to make any kernel calls.

Todd

0 Jason Enyart over 7 years ago in reply to ToddMullanix

Intellectual 605 points

By the way, in reading the PDF linked on that page, I think I may have discovered the source if my problem. I was using DefaultISR_BIOS.c which applied to the keyword interrupt to all of the ISRs. This seems to create a problem when the ISR is called through the dispatcher. Presumably this has something to do with dispatcher already managing context. I probably should have considered it earlier but it just didn't occur to me that it could be a problem since I didn't know what all the dispatcher was doing. Removing the keyword and configuring through the normal procedure seems to have fixed the stack problem.

0 ToddMullanix over 7 years ago in reply to Jason Enyart

TI__Guru* 96960 points

Jason,

I'm a little confused. Are you using Hwi_create for ISRs that are dispatched by the kernel and Hwi_plug for non-dispatched ISRs (i.e. zero-latency interrupts)? For the dispatched ones, you should be supplying a C function (without the interrupt keyword) .

Todd

0 ToddMullanix over 7 years ago in reply to ToddMullanix

TI__Guru* 96960 points

Jason,

Can I mark this as resolved?

Todd

0 Jason Enyart over 7 years ago in reply to ToddMullanix

Intellectual 605 points

Yes. Thank you.

C2000™︎ microcontrollers

C2000 microcontrollers forum

RTOS/TMS320F28375D: Migration of existing project into a new SYSBIOS/XDC version