AM3352: Control Status register' s value

Hello Kanae,

Thank you for the query.

I assume this is a custom board. can you ask customer to confirm if the bootmode configuration pins have been connected as per the processor recommendations and the values are as per the EVM.

I will check internally with the team.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.

I have already provided the customer's schematic in a private message when you supported us in the following thread so please check it out.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1356480/am3352-not-operate-normally-in-0-c/

Regarding the  boot mode configuration pins, the difference from the AM335x GP EMV is that the PU uses 100KΩ and the SYSBOOT1, 2, and 3 pins are connected to SN74CBTLV3257PW, which was not pointed out when we previously requested a schematic review.

The customer also reported to us that they had already checked with TI when they worked on the schematic,
and that the pointed out issues had been corrected at that time as well, but please let us know if you have any concerns.

Best Regards,
Kanae

Hello Kanae,

Thank you.

Kanae said:

Regarding the  boot mode configuration pins, the difference from the AM335x GP EMV is that the PU uses 100KΩ and the SYSBOOT1, 2, and 3 pins are connected to SN74CBTLV3257PW, which was not pointed out when we previously requested a schematic review.

The customer also reported to us that they had already checked with TI when they worked on the schematic,
and that the pointed out issues had been corrected at that time as well, but please let us know if you have any concerns.

Not sure i understand the comments. Please eloborate

The latching value seems to be influenced by BOOT_SEL input.

Can you check with customer if this pin is stable during power up and does not toggle.

The bootmode pins are required to be stable before the SOC latches the configuration.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.

I am sorry. I will try to organize and inform you a little more.
Regarding the boot mode configuration pins, the AM335x GP EMV has the following.

The difference from the customer's board is that PD uses 10KΩ, while EVM uses 100KΩ for PU.
Also, SYSBOOT pins 1, 2, and 3 are PU/PD via SN74CBTLV3257PW.
Please refer to the customer schematic previously provided in a private message.

Since you did not point out the contents of the customer's schematic in the thread above,
the boot mode configuration pins should not be a problem.

The customer also reported to us that TI has confirmed the contents of the customer's schematic
when they created the schematic.

Is the above information clear to you?
It would be easier to understand if you look at the customer's schematic.

Regarding BOOT_SEL, I will ask to check with customer if this pin is stable during power up
and does not toggle.

Best Regards,
Kanae

Hello Kanae,

Thank you.

The AM335x GP EVM uses a DIP switch and a voltage divider and hence 100K is used.

In the customer use case the 10K is uses to pull the IO high or low.

This should not be a concern.

Kanae said:

Regarding BOOT_SEL, I will ask to check with customer if this pin is stable during power up
and does not toggle.

I am waiting for the inputs.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your reply.
The status of BOOT_SEL pin is being checked with the customer.

I would like to confirm one point: even if the value of the Control Status register is wrong,
the H/W behaves as set and the BOOT Mode is reflected correctly in the system.
From this fact, it may be that the BOOT mode is not determined based on the value of this register.

Do you think that the current problem is caused by the following process?

1. Save the value in an unstable state in the register
2. After the system has stabilized, BOOT is executed regardless of the register value.
3. The stable Boot Mode setting is not reflected in the register value.

Best Regards,
Kanae

Hello Kanae,

Thank you.

Kanae said:

I would like to confirm one point: even if the value of the Control Status register is wrong,
the H/W behaves as set and the BOOT Mode is reflected correctly in the system.
From this fact, it may be that the BOOT mode is not determined based on the value of this register.

Do you think that the current problem is caused by the following process?

1. Save the value in an unstable state in the register
2. After the system has stabilized, BOOT is executed regardless of the register value.
3. The stable Boot Mode setting is not reflected in the register value.

I do not expect this. There are so many boot configuration. If customer board is executing the right boot, the boot mode is being detected correctly.

For the query on change in register, i would wait for customer to confirm the BOOT_SEL pin state during reset.

it is preferred that customer measures the BOOT_SEL pin level during reset.

Regards,

Sreenivasa

Hi Sreenivasa,

When I requested confirmation of the status of BOOT_SEL, the customer asked the following question.

Regarding the problem of the Control Status register value not being the expected value (SYSBOOT set value), when it is mentioned that the BOOT_SEL input is affected, are you referring to the BOOT_SEL signal in the customer's schematic (already provided)?

If it is correct, we have already confirmed that GPMC_A[1] (SYSBOOT[1]), GPMC_A[2] (SYSBOOT[2]), and GPMC_A[3] (SYSBOOT[3]), which are affected in the above schematic, are stable at the positive edge of PORz (PMIC_NRESPWRON). (SYSBOOT[3]), we have already confirmed that it is stable at the positive edge of PORz (PMIC_NRESPWRON). Please check the waveforms.

Please specify if the timing of acquisition is different.
If there are different understandings, please let us know what the BOOT_SEL input is referring to.

Best Regards,
Kanae

Hello Kanae, 

Thank you.

BOOT_SEL understanding is correct.

Could you please request customer to capture for  a longer time (ms)

I am checking with the team internally.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.

Here is BOOT_SEL waveform.
The power supply (+3.3V_VDDSHV6) rises about 5ms before POR of PMIC,
but Boot_SEL is stable at almost 0V.

2msdiv: CH1_PMICPWRON, CH2_+3.3V_VDDSHV6, CH3_BOOT_SEL

The customer shared with me the waveforms that were previously captured at 2ms_div
in a room temperature.

The waveforms are showing that the GPMC starts to operate after about 10ms,
and since the Boot is Nor Flash and connected by GPMC,
it is thought that the waveform variation is caused by Nor FLASH reading by RBL
and Nor FLASH reading by SBL.

Is it possible that the Boot_SEL signal is stable, the SYSBOOT signal is as set,
and the Control Status register values are different?

Best Regards,
Kanae

Hello Kanae, 

Thank you.

Kanae said:

I have not yet received a response from the customer regarding the status of BOOT_SEL,

As you wait for the response, can you please request customer to verify if all the bootmode pins have a pull connected during reset.

Does customer see this issue when the power cycle is done with the off period being short duration in few seconds and long duration being few minutes.

Regards,

Sreenivasa

Hi Sreenivasa,

Sorry for the post going the wrong way.
Thank you for your reply while I was editing the above post and uploading the BOOT_SEL waveform.

Sreenivasa said;
can you please request customer to verify if all the bootmode pins have a pull connected during reset.
Does customer see this issue when the power cycle is done with the off period being short duration in few seconds and long duration being few minutes.

Please let me know why you are confirming the above details.
Could you please let us know in advance what clues to investigate the cause of the problem if checked?

Best Regards,
Kanae

Hello Kanae, 

Thank you.

The above query May/may not help debug the issue but answers basic recommendations where it is always recommended not to leave any of the bootmode input pins open. A resistor is required to be connected.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.

If you check the schematic, you will see that the resistors are connected to each boot pin,
and you also confirmed in your previous post that the resistance values are OK,
so I believe that there is no problem regarding the resistor connections.

I will ask the customer for the following queries from you.

Sreenivasa said;
can you please request customer to verify if all the bootmode pins have a pull connected during reset.
Does customer see this issue when the power cycle is done with the off period being short duration
in few seconds and long duration being few minutes.

The main problem now is that the value in the Control Status register is different from
the actual H/W setting value, even on boards that start up normally at room temperature.

If we cannot clear this issue, we will not be able to proceed with debugging the original problem,
which is the startup problem at low temperatures.

Thank you for your continued cooperation.

Best Regards,
Kanae

Hello Kanae,

Thank you.

Kanae said:

If you check the schematic, you will see that the resistors are connected to each boot pin,
and you also confirmed in your previous post that the resistance values are OK,

I am looking for pulls on these resistor. Could you please point me to the resistors.

GPMC_A[9]
GPMC_A[8]
GPMC_A[10]

GPMC_A[11]

Kallikuppa Sreenivasa said:

Does customer see this issue when the power cycle is done with the off period being short duration in few seconds and long duration being few minutes.

Can you please check on this query.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.

GPMC_A8-A11 is not assigned as the BOOT pin since the following is shown on page 4 of the schematic,
are resistors required?

Best Regards,
Kanae

Hello Kanae,

Thank you.

I am not sure i understand your inputs.

The bootmode pins are defined by the processor and these need to be connected during power-up.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your reply.

The customer's BOOT MODE is SYSBOOT[4:0]=11011b (XIP boot) as per my post at the beginning of this thread.
The schematic is also set as above, and the waveforms during POR have been confirmed as expected for SYSBOOT[1]/GPMC_A1, SYSBOOT[2]/GPMC_A2, and SYSBOOT[3]/GPMC_A3, as I have reported so far.

Since GPMC_A8-A11 are not used for the BOOT pins used for this BOOT mode as described in the SYSBOOT pin assignment in the schematic above, but even if it is not used as a BOOT pin, the GPMC_A8-A11 resistor should be used against Is a resistor required?

Please point out any unclear points in the above.

Best Regards,
Kanae

Hello Kanae,

Thank you.

Kanae said:

Since GPMC_A8-A11 are not used for the BOOT pins used for this BOOT mode as described in the SYSBOOT pin assignment in the schematic above, but even if it is not used as a BOOT pin, the GPMC_A8-A11 resistor should be used against Is a resistor required?

Please point out any unclear points in the above.

Not sure if this is the cause. if customer can terminate these boot mode inputs and do a quick check that would be good.

Leaving the bootmode pin unterminated is not recommended.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.

I have asked the customer to confirm your inquiry.

The customer has replied with the understanding that the boot mode pin is a GPMC pin used for access during BOOT, and we report the customer's response as it is.

Sreenivasa said;
can you please request customer to verify if all the bootmode pins have a pull connected during reset.

→I recognized that you have already submitted the waveforms,
so you have asked me to check the connections on the actual board.
　I checked the board and found that all pullup/pulldown resistors are mounted as intended,
and I was able to measure pullup/pulldown resistance values by measuring resistance between Via.
　Since the resistance values could be measured, I believe that there is no defective mounting.

Sreenivasa said;
Does customer see this issue when the power cycle is done with the off period being short duration
in few seconds and long duration being few minutes.

→I checked the register value during the OFF period at 3 second intervals and at 3 minute intervals.
　The value is 0x0081037B in the circuit operation, but it is 0x00810377 in the register at all timings.
I checked 5 units, and the result is the same for all.

Sreenivasa said;
The above query May/may not help debug the issue but answers basic recommendations
where it is always recommended not to leave any of the bootmode input pins open.
A resistor is required to be connected.

→As you may have seen in the schematic, the SYSBOOT pin is either pulled up or pulled down.
I also confirmed that a pull-up or pulldown resistor is mounted on the implementation
by measuring the resistance between the Via.

GPMC_A8-A11 are not SYSBOOT pins, so I don't think they affect the BOOT setting.
These pins are Z (Hi-Z) on RESET, so electrically they should be PU/PD,
but since they are not SYSBOOT pins, logically Z (Hi-Z) should be fine.
Can you please provide a reasonable reason for requesting that
the customer should treat GPMC_A8-A11 as PU/PD?

Also, regarding Q1 in my first post, is the re-latch of nRESETIN_OUT causing this problem?

Best Regards,
Kanae

Hello Kanae,

Thank you.

I am reviewing the inputs.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.

As I need to report back to the customer, please let me know the expected reply schedule.

Best Regards,
Kanae

Hello Kanae,

Thank you. 

As i understand, all the bootmode pins are expected to have a resistor connected during power-up.

I will review the inputs and provide an answer by mid of the week.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.

I will share it with my customer.
I am awaiting your reply and appreciate your cooperation.

Best Regards,
Kanae

Hello Kanae,

Thank you, will do.

Regards,

Sreenivasa

Hello Kanae,

Please refer below.

https://www.ti.com/lit/an/sprabn2a/sprabn2a.pdf

2.2 SYSBOOT

Configuration and Required Termination ROM code depends on SYSBOOT configuration pins to determine the boot device order, boot configuration, and crystal frequency available on the board. These SYSBOOT pins are sampled only once on the rising edge of PWRONRSTn/PORz release and the Control Module register CONTROL_STATUS will reflect the configuration values as sampled. All 16 pins on SYSBOOT[15:0] must be terminated high or low and cannot be left floating. The desired high or low logic levels should be present at the pins before PORz is released to ensure correct sampling. For more information, see the Device Control and Status and Initialization chapters in the AM335x and AMIC110 Sitara Processors Technical Reference Manual. 

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your reply.

The information you provided has already been addressed on the customer's board.

"All 16 pins on SYSBOOT[15:0] must be terminated high or low and cannot be left floating."

State of customer's pins: PU/PD treated
SYSBOOT[0] /GPMC_A0(R1)
SYSBOOT[1] /GPMC_A1(R2)
SYSBOOT[2] /GPMC_A2(R3)
SYSBOOT[3] /GPMC_A3(R4)
SYSBOOT[4] /GPMC_A4(T1)
SYSBOOT[5] /GPMC_A5(T2)
SYSBOOT[6] /GPMC_A6(T3)
SYSBOOT[7] /GPMC_A7(T4)
SYSBOOT[8] /GPMC_A12(U1)
SYSBOOT[9] /GPMC_A13(U2)
SYSBOOT[10] /GPMC_A14(U3)
SYSBOOT[11]/GPMC_A15(U4)
SYSBOOT[12] /GPMC_A16(V2)
SYSBOOT[13] /GPMC_A17(V3)
SYSBOOT[14]/GPMC_A18(V4)
SYSBOOT[15] /GPMC_A19(T5)

Please let us know which part of the schematic you have already sent by private message
and which you think should be corrected.

The customer has again sent us a reminder with the following question.

Q. Please explain the reason for the mismatch between the circuit and
     the register value of the Control Status register,
     since the value in the Control Status register is not correctly reflected
     even though the SYSBOOT-related pins are properly treated.

Best Regards,
Kanae

Hello Kanae,

TI observation 

I am looking for pulls on these resistor. Could you please point me to the resistors.

GPMC_A[9]
GPMC_A[8]
GPMC_A[10]

GPMC_A[11]

TI suggestion

Is there a way to add pulls on these pins and do a test.

We have no way to confirm this is the issue. This is only a check to see if these changes helps.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.

Here is the results of checking the Control Status register value with GPMC_A[8..11] pulled up from my customer.

After pullup processing at 9.1kΩ for GPMC_A[8..11], the Control Status register values were checked.
As a result, there is no change in the Control Status register value.
The values are still different from the circuit settings.

Before pullup: 00810377h
After pullup: 　00810377h
Circuit setting: 0081037Bh

Best Regards,
Kanae

Hi Sreenivasa,

The following pins have been confirmed to be unaffected,
but how can it be confirmed why the BOOT settings are not reflected in the registers in any of the others?

GPMC_A[9]
GPMC_A[8]
GPMC_A[10]
GPMC_A[11]

Please also answer the following questions listed in my initial post

Q2: Is it possible that incorrect register values are recognized during startup, causing BOOT problems?

Q3: Should I check the information in TRM: Table 26-42 “Trace Vectors” to verify the SYSBOOT setting
　　on the H/W with other registers?

Best Regards,
Kanae

Hello Kanae,

Thank you.

Let me check with the expert and update you.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.

When can any expert reply to me about this issue?
I need to report it to my customer.

Best Regards,
Kanae

Hello Kanae,

Thank you for the follow-up.

Let me follow-up internally and update you.

Regards,

Sreenivasa

Hi Sreenivasa,

We have been waiting your feedback for two weeks and I would appreciate if you could tell us the current status of investigation. 

Best regards,

Yuta Ishii

Hello Yuta Ishii

Please refer inputs i received from the expert:

The CONTROL_STATUS register value should always reflect the latched bootmode pins.  If it shows a value that is different than expected, then somehow the bootmode pins were not stable when latched, or maybe there was a subsequent reset that relatched the signal before the value was read.  Since it appears sysboot[2] and sysboot[3] are different, they should focus on those signals. 

The sysboot signals 0x0081037B are setup to boot as XIP,UART0,SPI0,MMC0, but the CONTROL_STATUS shows MMC0 SPI0,UART0 USB0.  What is the intended boot media, and what did they intend to change in the sysboot signals (ie, what boot sequences did they intend to use).  As Paul alludes to, this seems to be an overly complicated design to change the sysboot signals for different purposes.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support!

As you have confirmed so far, the sysboot signal 0x0081037B is set to boot
as XIP,UART0,SPI0,MMC0, but CONTROL_STATUS indicates MMC0 SPI0,UART0 USB0.
Also, the intended boot media is XIP (NOR Flash), as you can see in the schematic I have already shared.

And in fact, it is not MMC0 SPI0,UART0 USB0 as shown in the register values,
but it is booting with XIP BOOT as set in the signal settings.
Does this occur because the register values have been relatched for some reason
after the BOOT Mode has been fixed and booted, and the register values have been changed?

I will check with the customer as to what they intended to change in the sysboot signal,
but I was previously given by the customer that they did not expect any boot mode other than XIP BOOT.

Best Regards,
Kanae

Hi Sreenivasa,

The customer's reply is as follows.

The boot media is XIP (Nor FLASH).
We do not change the boot sequence during operation.

The reason why sysboot[2] and sysboot[3] can be changed is that MicroSD booting was assumed
at the beginning of development, so the circuit configuration was designed
so that the boot media can be changed by jumpers and switches.

Currently, MicroSD boot is not used, so XIP boot is fixed.
The solder jumper is used to switch the boot media, so SYSBOOT is not changed during operation.
The waveforms of SYSBOOT[2..3] shared previously are also stable and
we believe that the circuit is fixed.

Is the above the answer to your question? If not, please contact us.

Best Regards,
Kanae

Hello Kanae

Thank you.

Did customer remove the buffer and hardwire the boot configuration?

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.

As posted above, the customer is using a jumper to keep SYSBOOT unchanged
in the current circuit, so it is fixed, but the waveform of SYSBOOT[2..3] is also stable
and the circuit is considered fixed, so the schematic itself is not changed
and the buffer has not been removed.

Best Regards,
Kanae

Hello Kanae

Thank you.

The bootmode configuration is not expected to change if the boot mode setting were stable.

The only concern team has was with the implementation of the bootmode configuration that looks complex that it could have been.

I am not sure if we answered this query - is this issue observed on all the boards and is consistent (yes is the answer),

Does customer have any other design using the same processor and had any similar observation.

Regards,

 Sreenivasa

Hi Sreenivasa,

Thank you for your support.

I will report the following views to the customer.
Is my understanding correct that the views here are the answers to Q1 that I am asking in my first post?
　Sreenivasa said;.
　The bootmode configuration is not expected to change if the boot mode setting were stable.
　The only concern team has was with the implementation of the bootmode configuration that
　looks complex that it 　could have been.

I am not sure I understand the meaning of the following sentence.
Are you asking if all of your customer's boards are experiencing the same problem (register values are not reflected correctly)?
　Sreenivasa said;.
　I am not sure if we answered this query - is this issue observed on all the boards and is consistent (yes is the 　answer)

I will check with the customer about the following question.　
　Sreenivasa said;
　Does customer have any other design using the same processor and had any similar observation.

Best Regards,
Kanae

Hello Kanae

Thank you.

Kanae said:

I am not sure I understand the meaning of the following sentence.
Are you asking if all of your customer's boards are experiencing the same problem (register values are not reflected correctly)?
　Sreenivasa said;.
　I am not sure if we answered this query - is this issue observed on all the boards and is consistent (yes is the 　answer)

This is correct. trying to understand if this is a specific board or batch issue.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.
The customer inquired about the following comment from you

　Sreenivasa said;.
　The bootmode configuration is not expected to change if the boot mode setting were stable.
　The only concern team has was with the implementation of the bootmode configuration that
　looks complex that it could have been.

Q. If the SYSBOOT value is operating as intended at the SYSBOOT latch timing (POR),
 Status Control does not match, the SYSBOOT value at the latch timing (POR) of SYSBOOT
 will work as intended, so no problem can occur.　Is this correct?
We have checked the operation by removing the boot switching circuit and 
using only pullup/pulldown circuit with resistors, but the Control Status register value was
the same (0x00810377). There seems to be no effect of circuit complexity.

The answer is "Yes. This is the same problem with N=5." to the following your question.

　Sreenivasa said;.
　I am not sure if we answered this query - is this issue observed on all the boards and
    is consistent (yes is the answer)

Best Regards,
Kanae

Hello kanae, 

Thank you.

Kanae said:

If the SYSBOOT value is operating as intended at the SYSBOOT latch timing (POR),
 Status Control does not match, the SYSBOOT value at the latch timing (POR) of SYSBOOT
 will work as intended, so no problem can occur.　Is this correct?

Not sure i understand the statement, please ask customer to elaborate.

Kanae said:

We have checked the operation by removing the boot switching circuit and 
using only pullup/pulldown circuit with resistors, but the Control Status register value was
the same (0x00810377). There seems to be no effect of circuit complexity.

Thank you for the update.

Does customer have an alternate boot option to configure and test?

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.
My apologies for the confusing expressions.

　Sreenivasa said;.
　The bootmode configuration is not expected to change if the boot mode setting were stable.
　The only concern team has was with the implementation of the bootmode configuration that
　looks complex that it 　could have been.

To your response above, the customer's inquiry is as follows.

We have checked the operation with the circuit for Boot switching removed
and only pullup/pulldown by resistor, but the Control Status register value was the same (0x00810377).
From this it appears that there is no effect of the complexity of the boot mode configuration implementation.

Currently, the SYSBOOT value is behaving as configured in hardware with SYSBOOT latch timing (POR).
In this case, is it correct to understand that even if Status Control does not match,
the problem cannot occur  because the SYSBOOT value operates correctly at latch timing?

Also, I would like to know if the following question, which I have confirmed in the first post of this thread,
can be rewritten by being re-latched after BOOT, and if so, can you please get an answer from the experts?

Q1: Is there a possibility that the SYSBOOT setting on the H/W is not reflected
in the Control Status register, as described in TRM: 8.1.7.3.2 PORz sequence as follows?
Is the problem reported by the above customer?

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
- PORz pin at chip boundary gets asserted (goes low).
Note: The state of nRESETIN_OUT during PORz assertion should be a don't care,
it should not affect PORz (only implication is if they are both
asserted and nRESETIN_OUT is deasserted after PORz you will get re-latching of
boot config pins and may see warm nRESETIN_OUT flag set in PRCM versus POR).
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

Best Regards,
Kanae

Hi Sreenivasa,

Thank you for your support.

When can I get a response from your experts regarding the above answer?
There is no boot option on the customer's current board.
I need to report this to the customer, so please just let me know when you will respond.

Best Regards,
Kanae

Hello kanae, 

Thank you.

I am checking with the expert.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your support.

When can I get a response from your experts regarding the above answer?
Please let us know your progress.
I need to report this to the customer, so please just let me know when you will respond.

Best Regards,
Kanae

Hello kanae, 

Thank you.

I am following with the expert.

Regards,

Sreenivasa

Hello Sreenivasa,

This is just a reminder.  The problem still remains; the register values are not reflected correctly. We'd like to hear from you if you have any updates. Could you kindly give your any ideas for the question below?

Kanae said:

can be rewritten by being re-latched after BOOT, and if so, can you please get an answer from the experts?

Q1: Is there a possibility that the SYSBOOT setting on the H/W is not reflected
in the Control Status register, as described in TRM: 8.1.7.3.2 PORz sequence as follows?
Is the problem reported by the above customer?

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
- PORz pin at chip boundary gets asserted (goes low).
Note: The state of nRESETIN_OUT during PORz assertion should be a don't care,
it should not affect PORz (only implication is if they are both
asserted and nRESETIN_OUT is deasserted after PORz you will get re-latching of
boot config pins and may see warm nRESETIN_OUT flag set in PRCM versus POR).
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

Thank you,

Alisa