Forums

Hello,

1) The datasheet only lists one (1) SCI module for the C28x.

2) I am not sure what you mean.  I will let someone else try to answer this for now.

Regards,
Daniel

1) I found out that the best/fastest way to locate pins is to use the pin mux utility. Search for the PinMux_v100 folder on your ControlSuite that you'll find it. But the other answer is right, the C28 core only got 1 SCI !

Hi Nick

Nick Neander

2) Because there is an error in the ROM (as stated in the dual core examples), I cannot run the processor standalone with the same build that I debug with. Is there a way to tell from ARM code that the debugger is connected?

regarding your Q2) above, nope there is no way to tell if device is running standalone or not. But you wouldn't need that - its very simple if you can follow below.

Code development phase and stand-alone testing phase;-

> you have debugger connected to both subsytems/cores - the GEL scripts take care of RAM-INITs, so you don't have to worry about this stuff.

> when you connect to the device and load your application code in flash or RAM, you are not running boot ROM on either CPU - right? So you don't have to worry about C-Boot ROM errata.

> on Master subsystem appication main() routine , comment out the function call that sends IPC to C-Boot ROM - because you don;t have C-Boot ROM running in this development phase any way. You can Identify this function call in your main as - "    IPCMtoCBootControlSystem();    "

> After you load your applicaiton on Control subsytem and Master subsystem RAM/Flash - just run them.

> After you are confident in your application and want to test stand-alone operation, put the function back in your master subsystem main() routine - flash the updated code.

> disconnect debugger - power off and On- the function call sequence that sends IPC from master application to control subsytem boot ROM is well tested and you can be confident on that. Just make sure you program your application properly as per the flash-entry-point defined in C-Boot ROM.

Please let us know if you have any questions on above or if you need any help.

Best Regards

Santosh

@ question 1;

From concerto manual.

The SCI modules support digital
communications between the CPU and other asynchronous peripherals that use the standard
non-return-to-zero (NRZ) format. The SCI receiver and transmitter each have a 16 -level deep FIFO for
reducing servicing overhead, and each has its own separate enable and interrupt bits. Both can be
operated independently for half-duplex communication, or simultaneously for full-duplex communication.

Table 15-1. SCI-A Registers
Name Address Range Size (x16) Description
SCICCR 0x0000-7050 1 SCI-A Communications Control Register
SCICTL1 0x0000-7051 1 SCI-A Control Register 1
SCIHBAUD 0x0000-7052 1 SCI-A Baud Register, High Bits
SCILBAUD 0x0000-7053 1 SCI-A Baud Register, Low Bits
SCICTL2 0x0000-7054 1 SCI-A Control Register 2
SCIRXST 0x0000-7055 1 SCI-A Receive Status Register
SCIRXEMU 0x0000-7056 1 SCI-A Receive Emulation Data Buffer Register
SCIRXBUF 0x0000-7057 1 SCI-A Receive Data Buffer Register
SCITXBUF 0x0000-7059 1 SCI-A Transmit Data Buffer Register
SCIFFTX 0x0000-705A 1 SCI-A FIFO Transmit Register
SCIFFRX 0x0000-705B 1 SCI-A FIFO Receive Register
SCIFFCT 0x0000-705C 1 SCI-A FIFO Control Register
SCIPRI 0x0000-705F 1 SCI-A Priority Control Register
Table 15-2. SCI-B Registers
Name Address Range Size (x16) Description (1) (2)
SCICCR 0x0000-7750 1 SCI-B Communications Control Register
SCICTL1 0x0000-7751 1 SCI-B Control Register 1
SCIHBAUD 0x0000-7752 1 SCI-B Baud Register, High Bits
SCILBAUD 0x0000-7753 1 SCI-B Baud Register, Low Bits
SCICTL2 0x0000-7754 1 SCI-B Control Register 2
SCIRXST 0x0000-7755 1 SCI-B Receive Status Register
SCIRXEMU 0x0000-7756 1 SCI-B Receive Emulation Data Buffer Register
SCIRXBUF 0x0000-7757 1 SCI-B Receive Data Buffer Register
SCITXBUF 0x0000-7759 1 SCI-B Transmit Data Buffer Register
SCIFFTX 0x0000-775A 1 SCI-B FIFO Transmit Register
SCIFFRX 0x0000-775B 1 SCI-B FIFO Receive Register
SCIFFCT 0x0000-775C 1 SCI-B FIFO Control Register
SCIPRI 0x0000-775F 1 SCI-B Priority Control Register

I am a bit confused as to why there are registers for the 2nd peripheral...

@ question 2;

I have been doing exactly that and its a bit annoying. I shouldn't to have to rebuild and re-program to run stand alone. I'm doing a project that may require a demo at short notice and it would be nice to be able to just grab the board and go. Also, while learning the process of "running from ram" I can't very well see if its working if the debugger is loading the ram for me. Its the IPC command that I would like to skip if the debugger is running. I know how to do this with .NET but not in C. Could I tell by the clock? Does the debugger set a different clock rate?

There is a footnote below Table 15-2

(2) SCIB is an optional peripheral. In some devices this may not be present. See the device-specific data sheet for peripheral availability.

On Concerto, there is only SCI-A.

Since the SCI peripheral can be identical between devices, it is easier to use the same SCI information across all devices (with disclaimers such as footnote 2) instead of customizing it for each one.

I agree that this can be misleading but please also keep in mind the manual is still in an early stage and is meant for lead customer use and is not a final document. 

Thanks for the advice.

I'm having trouble pointing the target config at the new gel file (which I added to my project). I cant find where to select the gel to use for a launch.