TMS320C5517: GPIOs Output Low Signal When Booting Program

Massa1

Expert 1050 points

Part Number: TMS320C5517

Hi, all;

We developed a DSP board using aTMS320C5517.

Some experimental boards worked well.

Then we produced about 300 boards, and about one percent boards are malfunctioned.

We are using GPIO13 and GPIO17 as information output to host processor.

Almost DSPs, GPIO ports can keep Hi-Z when boot-loading process. Hi-Z is reset status.

However some DSPs, GPIO13 and GPIO17 outputted Low signal while boot-loading.

I don't know about another GPIO ports will be, because I didn't observe them.

Getting the low signal, the host processor misunderstood the status of C5517 board and hung up the system.

We can not find this issue in the errata sheet. We want to know what is happened.

And we need the way how to prevent output signal while booting process.

B.R.

Massa.

over 6 years ago

0 Cvetolin Shulev-XID over 6 years ago

TI__Guru 65405 points

The team is notified. They will post their feedback directly here.

BR
Tsvetolin Shulev

0 Mark Mckeown over 6 years ago

TI__Mastermind 29270 points

Hi Massa-san,

What boot mode is being used?

These two GPIOs are muxed with HPI data signals.
GP[13]/UHPI_HD[3]
GP[17]/UHPI_HD[7]

The reset state of these pins is only applicable while reset is asserted. After reset, the bootloader configures the EBSR PPMODE parallel port pin muxing in order to boot from different peripherals. These two pins are only muxed as GPIOs when PPMODE is 1 or 6. In PPMODE 0 (HPI), they are HPI data signals. But in all other modes, they are "reserved".

For instance, during SPI boot the bootloader reconfigures the EBSR from PPMODE 5 to PPMODE6 in order to access the two possible SPI pin mux modes. I dont know what these two GPIOs will do when in MODE 5. I would have to dig around internally to figure out what is actually present on the pins in any other mode.

Depending on the boot mode, it may not be a good idea to rely on these two GPIOS for status.

But the customer may be able to add -reg_config parameters when building their boot image to write to registers that control the internal pull-downs of these two pins (if they are floating).

To check if these pins are actually high-Z, the customer might add a pull-up resistor and probe them throughout the bootloader process.

Regards,
Mark

0 Massa1 over 6 years ago in reply to Mark Mckeown

Expert 1050 points

Hello, Mark
Thank you for your response.
The customer already pull-up the ports with 10kohm registers.
Then when the internal pull-down registers work, the pins must keep high level.
We also measure the signals with 1kohm pull-up registers now, but level not changed.
I'd like to know the GPIO pins may change the direction from Input to Output while booting.
If no possibility, we will guess the device works with wrong behavior.
We can't know the boot loader code in ROM. Please tell me just the possibility.
B.R.
Massa

0 Mark Mckeown over 6 years ago in reply to Massa1

TI__Mastermind 29270 points

Hi Massa-san,

I will need to know the bootmode used to check the bootloader source code to see how these two pins are being pinmuxed. They may not be muxed as GPIOs at all, and may be muxed into a reserved mode.

I dont think we can share the bootloader code.

Regards,
Mark

0 g.f. over 6 years ago in reply to Mark Mckeown

Guru 15510 points

Hi Mark,

Thank you for the reply.
I'm working with Massa, and I'm sorry about the delayed response from us.

Actually these issue are happening at our customer.
They are using McSPI boot mode and the GPIO(GP_[17]& GP_[13]) are pulled up with 10kohm externally.

As Massa mentioned above, this issue occurs in 3 boards(total numbers of board is 300)
everytime the board is powered-on.

So, we debugged the board as following method, and found out that it seems that PPMODE was set to mode 4 by
internal bootloader, but in good board which GPIO doesn't goto low level the PPMODE was set to mode 6.
While debugging both boards, the boot mode is McSPI and there are no difference of software/hardware between these two boards.

Following is how we debugged.
1.Modified the user boot image.
Placed the register reading code(storing registers value in to global variable)
at top of the main()function before executing other codes.
The read registers are EBSR and GPIO(IODIR1/2, IODATAOUT1/2).
Just after reading these register, it enters infinite loop immediately.
2.After flashing the boot image, Power-On the board.
3.Then connect to CCS, the program are stopping at the infinite loop.
4.Check the global variables. The PPMODE was set to mode4 in the problem board and mode6 in the good board.

So, we are confusing why the PPMODE are diffent between two boards.
Could you explain why this is happening and what value are set to PPMODE by bootloader usually in McSPI boot mode?
And we want to know how the GPIO pins act if PinMux was set to reserved pin(PPMODE mode4).

By the way, I don't know why but when the target are connected to CCS via XDS560
and then hardreset the board, this issue(GP_[17], GP_[13] drive to low) won't occur.

best regards,
g.f.

0 g.f. over 6 years ago in reply to Mark Mckeown

Guru 15510 points

Hi Mark,

We have some updates for this issue.

We asked the customer to try using "register configuration" option as written in
application note(Using the TMS320C5517 Bootloader:SPRABP1) page.8 [2.3 Register Configuration]
and page.11 [3.1.1.2 Creating an Unencrypted Boot Image with I/O Register Configuration].

They created boot image with the following register configuration options
which makes GP_[17] to be High Output.
***********************************
-reg_config 0x1c00,0x1000 /*-EBSR Register, value=0x1000 (PPMODE=1)*/
-reg_config 0x1c07,0xFFFF /*-IODIR2 Register, value=0xFFFF(GP_[17] = Output)*/
-reg_config 0x1c0B,0xFFFF /*-IODATAOUT2 Register, value=0xFFFF(GP_[17] Output High)*/
-delay 0x100
***********************************

Result:
After RESET is deasserted and during bootloader are running,
GP_[17]pin are outputting High level signal and never output low level during bootloader execution.

So, it seems using register configuration options will fix this issue.
But our customer are saying that this method can't be used as workaround
because specification of C5517 bootloader are not cleared.

Our customer are requesting the answer of following questions:
1.
If above register configuration option are not used,
one device will boot without outputting low level from GP_[17]
but another device GP_[17] pin will output low level during bootloader.
Why there are such differnece between devices?

2.
At what timing is bootloader configuring the registers related to above reg config option?
Before bootloader are doing this configuration, does bootloader configure pins and GPIO ports?

3.
They are requesting the documentation of specification from TI which wrote about that
the GPIO port configuration will be fixed by using above register configuration option,
and never be changed to other unknown configuration by bootloader or other C5517 resources.

best regards,
g.f.

0 Mark Mckeown over 6 years ago in reply to g.f.

TI__Mastermind 29270 points

Hi g.f.,

I am looking into this issue again. This is what I have found in the bootloader source code so far...

When booting from McSPI (BOOTMODE = 0xD or 0xE), the bootloader sets EBSR bit fields...
PPMODE to MODE0 (HPI)
SP1MODE to MODE1 for McSPI
SP0MODE to MODE0 (MMC/SD)

Nowhere in the bootloader code does PPMODE get set to MODE 4.
The only place in bootloader code that sets PPMODe to MODE 6 is in the SPI boot (not McSPI)

=-=-=-=-

"At what timing is bootloader configuring the registers related to above reg config option?
Before bootloader are doing this configuration, does bootloader configure pins and GPIO ports?"

Bootloader reads first two bytes from memory looking for valid boot signature ("0x09AA")
Bootloader reads next two bytes for program entry point
Bootloader reads next byte for number of reg configurations
bootloader reads two bytes for every reg configuration and writes the register with provided value
Bootloader reads 1 byte for size of next section
Bootloader reads 2 words for destination address of section
Bootloader reads section (size of section = previously read size)
Bootloader reads size of next section and repeats above two lines until all sections read
Bootloader branches to entry point

=-=-=-=-

What are the results when reading boot mode pins (from register CSL_SYSCTRL_REGS->BMR) on both good boards and boards with the issue?
- I want to confirm that the bootmode is getting latched correctly on both boards.

I cannot yet explain how the EBSR PPMODE enters MODE4.

Regards,
Mark

0 g.f. over 6 years ago in reply to Mark Mckeown

Guru 15510 points

Hi Mark,

Thank you for the reply.

We have additional information from our customer.

During debugging the boot, customer checked the following register value
at the begining of main function.
Some registers vaule are different every time the board is booted up.
We are confusing that register values are different every boot time.

This is not related to the board.
It is the same for both normal board and the board with issue.

<Value of board with issue>
**********************************************
PCGCR1 = C7E6h(1st Time), C7C4h(2nd Time)
PCGCR2 = 2562h(1st Time), 6562h(2nd Time)
EBSR = 412Eh(1st Time), 4328h(2nd Time)
IODIR1 = 2DF7h(1st Time), 2DFFh(2nd Time)
IODIR2 = 2B44h(always this value)
IODATAOUT1 = 9CFCh(1st Time), 98FEh(2nd Time)
IODATAOUT2 = 2E6Dh(always this value)
**********************************************

<Value of normal board>
**********************************************
PCGCR1 = BDA4h(always this value)
PCGCR2 = C514h(always this value)
EBSR = 6D86h(1st Time), 4D84h(2nd Time)
IODIR1 = 73BA(always this value)
IODIR2 = 819Dh(1st Time), C59D(2nd Time)
IODATAOUT1 = 5E1Bh(1st Time), 5E9Bh(2nd Time)
IODATAOUT2 = 9733h(always this value)
**********************************************

Repeat the booting and checking the register,
the PPMODE value was change randomly every time the board booted up.
So, it seem that PPMODE value and the GPIO register value are not related to the issue.

----
>What are the results when reading boot mode pins (from register CSL_SYSCTRL_REGS->BMR) on both good boards and boards with the issue?
> - I want to confirm that the bootmode is getting latched correctly on both boards.
----
I'm asking to the customer. So, please wait for a while.

best regards,
g.f.

0 g.f. over 5 years ago in reply to g.f.

Guru 15510 points

Hi Mark,

There are corrections about the value of each register which I previously posted.
When customer checked the register value, they didn't use 'iport' keyword.
So, they were checking the data area not I/O port register area.

They again confirmed the register by using 'iport' keyword
and had the following values :
//////////////////////////////////////////////////////////
EBSR = 0x0400 (PPMODE=0(UHPI))
BMR = 0x03A0 (BootMode[5:4]=01(12.00MHz or 12.288MHz), BootMode[3:0]=1101(McSPI 10MHz))
IODIR1 = 0x0000 (All input)
IODIR2 = 0x0000
IODATAOUT1 = 0x0000
IODATAOUT2 = 0x0000
//////////////////////////////////////////////////////////

It seem the value is as expected.

From the above register value(PPMODE), GP[17]pin are set to UHPI_HD[7] function.
But bootmode is McSPI so that UHPI are idled by bootloader and it's unfunctional.
In such case, are there possiblity of driving the UHPI_HD[7]pin to Low by UHPI?
Or are the pins in unknown state?

best regards,
g.f.

0 g.f. over 5 years ago in reply to g.f.

Guru 15510 points

Hi Mark,

We have some updates.

As I previously posted, PPMODE and GPIO registers value seems its in default state of McSPI boot mode.
In McSPI boot mode, PPMODE will be set to UHPI.
So, GP[17]pin is set as UHPI_HD[7] function.

We wonder what will happen if PPMODE are set to GPIO(mode 1) during bootloader by using "register configuration" feature.
So, our customer tried this method, only setting PPMODE to mode1 by using "register configuration".
The result was no issue happened(GP[17] never drive to low level).
So, we are guessing that UHPI mode are causing this issue but we don't know why.
How do you think about this?

best regards,
g.f.

0 Mark Mckeown over 5 years ago in reply to g.f.

TI__Mastermind 29270 points

Hi g.f.,

I was able to verify the register values on my EVM using the same boot mode settings. I just booted from McSPI without any boot image in the SPI flash on the C5517 EVM. Then I connected to the target with JTAG, but without a GEL file. The GEL file would have reset and initialized the processor, but I wanted to see the state that it is in after the bootloader has initialized the registers.

During the bootloader execution of McSPI boot, the HPI peripheral is clock gated by the PCGCR2 register.

Very early in the bootloader clock gates are closed (clock stopped) to all peripherals except for the CPU (SYSCLKDIS bit). Then as they are needed, each peripheral has its clock enabled. HPI is only enabled if the HPI boot mode is chosen. It could be enabled with a reg_config command.

Can the customer verify that the PCGCR2 register has bit 0 set high (clock disabled)?

Just before the peripheral clocks are all disabled, the bootloader code performs a peripheral reset on all peripherals. The PCGCR reset state is all clocks active, so they have a clock during the peripheral reset. UHPI is in the Peripheral Group 4 (bit 15 of PRCR).

So the HPI signals will be in their reset state before the clock is gated to the HPI peripheral. The pins reset to HPI mode instead of HPI GPIO mode.

According to the TRM, UHPI data bus pins are Hi-Z when UHPI is in ZPOR reset, when there are no read accesses occurring, or when HPIENA=0.

So then only the internal pull down will control GP[17]/ UHPI_HD[7]. IPD is enabled at reset, and apparently not modified by the bootloader.

I would expect GP[17]/ UHPI_HD[7] to be weakly pulled down. Does this match the behavior observed by the customer?

=-=-=-

If changing the EBSR PPMODE to MODE1 with -reg_config works for the customer, I do not see any problem with this. They can further configure the GPIOs to drive out as a high or low level with -reg_config also.

Regards,
Mark

0 g.f. over 5 years ago in reply to Mark Mckeown

Guru 15510 points

Hi Mark,

Thank you for the reply.

>So the HPI signals will be in their reset state before the clock is gated to the HPI peripheral. The pins reset to HPI mode instead of HPI GPIO mode.
>According to the TRM, UHPI data bus pins are Hi-Z when UHPI is in ZPOR reset, when there are no read accesses occurring, or when HPIENA=0.
>So then only the internal pull down will control GP[17]/ UHPI_HD[7]. IPD is enabled at reset, and apparently not modified by the bootloader.

We understood that UHPI data bus are in Hi-Z when UHPI is in ZPOR reset and
internal pull down will be enabled.
So, we are expecting that UHPI_HD[7]/GP[17] pin will go to high level
because these pins are pulled up(10kohm) externally in the custom board.
But it's in low level so that we are guessing that someone in C5517 are driving the UHPI_HD[7] pin to low.

>So then only the internal pull down will control GP[17]/ UHPI_HD[7]. IPD is enabled at reset, and apparently not modified by the bootloader.
>I would expect GP[17]/ UHPI_HD[7] to be weakly pulled down. Does this match the behavior observed by the customer?

I think this doesn't match the behavior.

>If changing the EBSR PPMODE to MODE1 with -reg_config works for the customer, I do not see any problem with this.
>They can further configure the GPIOs to drive out as a high or low level with -reg_config also.

As so far, it's working for the customer.
But in Bootloader application report(sprabp1) it said as follow:
********************************************************************************
NOTE : Using the register configuration feature to reprogram register settings
may cause the bootloader to fail
********************************************************************************
The customer can't decide whether to use this feature by above NOTE.
So, the customer are requiring the guarantee from TI
that "-reg_config" will be workaround for this issue.

best regards,
g.f.

0 g.f. over 5 years ago in reply to Mark Mckeown

Guru 15510 points

Hi Mark,

As you requested, the customer checked the PCGCR2 register bit 0 of the board with the issue.
The bit 0 of PCGCR2 register was set to high(UHPI clock disabled).

UHPI_HD[7]/GP[17] pin are drived low until the initialization code in the user program runs.
In the initialization code, UHPI_HD[7]/GP[17] pin will be set as GP[17](output)
and it will be set to outputing high.

best regards,
g.f.

0 Mark Mckeown over 5 years ago in reply to g.f.

TI__Mastermind 29270 points

Hi g.f.,

With my C5517 EVM, the GPIO[17] behavior is as expected.

Throughout the bootloader execution, GPIO17 is high-Z with some apparent very weak internal pull-down
I tested with no valid boot image in SPI flash (first two bytes are 0x0000)...
- with 2.2k pull-up, the signal stays at 3.3V
- without any pull, the signal stays low at 0V

With no valid boot image in SPI flash and no pull-up on GPIO17...
After bootloader fails to find any boot image on McSPI peripheral, the XF pin toggles at 25Hz. Connecting to CCS without any GEL file shows the bootloader is still executing (PC = 0xFFA266). The EBSR parallel port mode shows MODE0 (HPI mode). GPIO17 is still low at 0V. Changing EBSR to MODE1 (GPIO), the default GPIO direction is in, and GPIO17 is still low (I am able to pull-up, and it slowly settles back low after removing the pull-up). The signal goes high after writing a 1 to the OUT17 bit in IOOUTDATA2 register.

With no valid boot image in SPI flash and with a pull-up on GPIO17...
GPIO17 is high at 3.3V. Changing EBSR to MODE1 (GPIO), the default GPIO direction is in, and GPIO17 remains pulled high. The signal goes low only after writing a 1 to DIR17 of IODIR2 and leaving OUT17 as 0 in IOOUTDATA2.

With the PDINHIBR3 PD7PD bit set high, the pull-down on GPIO17 becomes disabled. When the pull-up is present, the voltage rises slightly (the internal pull-down is no longer contending with the external pull-up).

All these behaviors are as expected based on the bootloader source code and reset states of HPI and GPIO peripherals.

The reason for these two boards acting differently must be explained somehow.
Can you ask the customer to repeat my experimentation with the pull-up resistor, connecting to CCS without a GEL file, and changing the same registers I did: EBSR, IODIR2, IOOUTDATA2, and PDINHIBR3?

There must be some difference with these two boards where GPIO17 drives low instead of being weakly pulled low...

Regards,
Mark

0 g.f. over 5 years ago in reply to Mark Mckeown

Guru 15510 points

Hi Mark,

Thank you for the reply.

The customer checked the behavior with changing the registers as like you did.

With no valid boot image in SPI flash and with a pull-up on GPIO17...
1.After connecting to CCS without GEL file, the GP[17] pin is 2.25V.
2.Set EBSR.PPMODE bit to Mode1(GPIO mode), GPIO direction is input(default),
the GP[17] pin is 2.25V .
3.Change IODIR2 register GP[17] direction to output, and set IODATAOUT2 register to output High from GP[17]pin.
The GP[17] pin output 3V.
4.Set IODATAOUT2 register to output Low from GP[17] pin.
The GP[17] pin output 0V.

And when setting PUDINHIBR3 register bit[7] to '1'(pulldown disable),
the GP[17] pin is High level(3V). (They checked the pin after above step 1 and step3)

In the customer board with issue, the issue won't occur if the board is connected with CCS.
They checked with no valid boot image in SPI flash, and also with valid boot image in SPI flash.

With valid boot image in SPI flash...
After booting up, they connect the board to CCS, then use hardware reset to reboot the C5517 with CCS connected.
In this case, the GP[17] pin didn't driven to low level when rebooting.

best regards,
g.f.

0 g.f. over 5 years ago in reply to Mark Mckeown

Guru 15510 points

Hi Mark,

Thank you for the reply.
(I got e-mail from E2E but it seems that your post isn't reflected to this forum)

>That behavior is as I expected.
>For 1. and 2., the internal pull-down is acting against the external pull-up,
>so the measured voltage is the "resistor divider" value of the pull-up and the pull-down.

But this expected behavior is only when the board are connected to CCS.

>Can they read back the BootMode Register (BMR) [1C34h] to see what boot mode has been latched
>after the GP[17] signal is driving low instead of Hi-Z? BMR[8:5] holds the BootMode[3:0] bits.

When they read back the BootMode Register(BMR), the value was as follow:
********************************************************************************
BMR = 0x03A0 (BootMode[5:4]=01(12.00MHz or 12.288MHz), BootMode[3:0]=1101(McSPI 10MHz))
********************************************************************************

>See if removing the GEL file from the target configuration changes any of the
>results from the previous register comparison also.

When debugging and reading the register values, the GEL file is always removed.

>I have another question. How does the host processor use these two GPIOs that get driven low on
>these boards with the issue that affects the boot operation?
>Why does it matter that these pins do not get driven low during boot verses once the application code
>starts running, after boot? Perhaps it was explained in a previous post?

The host processor bootup first and after host boot are completed the C5517 starts booting.
Host are looking these GPIO as status and if it is low level, the host send some signal to the C5517.
Host waits for the acknowledge against the signal from the C5517 application.
But in board with issue, GPIO are driven low(unexpected) during internal bootloader are running
so that the host will send the signal to C5517, but as C5517 are in booting phase,
no acknowledge will be sent from C5517 and so the host will hung up.
So, that is why the GPIO need to be High level during boot process.

best regards,
g.f.

Processors

Processors forum

TMS320C5517: GPIOs Output Low Signal When Booting Program