Reset Problem of B4860

[weiwangw]

Hi,

     We designed a board which refer to the B4860QDS Evaluation Board. Recently, we met a problem when reseting the chip. Sometimes, we reset the chip, it respond nothing. So, I think the B4860 chip hult running. Our schematic is designed refer to B4860QDS, and we removed some parts of B4860QDS schematic, include K10 part.

     So, I have two question about that:

     a) What may case the problem we have met?

     b) I deleted the K10 part, is that effect the reset sequence?

[weiwangw]

I have changed the code as your advice, make the flash reset signal asserted for 1ms and 100us, but I still meet the situation that B4860 cant reset normally. Maybe its not the reset signal caused this problem.

Thank you!

[Bulat]

Can you take waveforms of PORESET and flash reset signals for reviewing?

[weiwangw]

     Sorry, the reset signal doesnt draw in the picture, but it connects to FPGA in fact.

     I just measured the reset time of NOR flash during reset process, it's about 440ms. Here is the capture:

Thank you!

[Bulat]

Actually I asked "timing of the flash reset signal in relation to PORESET". Does  your figure mean that PORESET is also about 440ms?

[weiwangw]

PORESET is a little longer than flash reset signal, PORESET is about 480ms. In fact, after press the reset button, FPGA give PORESET, then set NOR flash reset signal.

[Bulat]

Can you change the code in the FPGA and make NOR flash reset signal shorter than PORESET.  Like the following sequence:

1. PORESET asserted;

2. Flash reset asserted for 1ms (or 100us);

3. PORESET asserted for remaining  440ms (or so).

[Bulat]

So the B4860 reads RCW from a NOR flash.

What is the part number of the flash?

Does the flash have Reset input signal? If so, what is the connection of this signal on your board?

Regards,

Bulat

[weiwangw]

     The part number of NOR flash is S29GL01GS11TFI010.

     The flash reset connects to FPGA, during reset process, the FPGA send low active reset to the NOR flash.

Like B4860QDS, the schematic diagram is this:

     Thank you!

[Bulat]

I do not see reset signal in the schematic diagram.

Anyway, what is the timing of the flash reset signal in relation to PORESET?

[Bulat]

Again, this is really strange: "I had measured several times, the HRESET asserting is about 4us prior to PORESET negation". As I wrote, the B4860 can not know when PORESET will be negated, so "about 4us prior to PORESET negation" looks like a fantastic feeling of the B4860. It would be interesiting to extend or shorten PORESET pulse width, would the B4860 be able to track these changes and assert HRESET 4us prior to PORESET negation anyway?

Possible reason of the RESET_REQ assertion is an error during RCW reading. Try to check all related signals using a scope, e.g. cfg_rcw_src[0:8], control signals of the RCW memory source.

Regards,

Bulat

[weiwangw]

1)  The HRESET asserting is about 4us prior to PORESET negation:

     The PORESET signal drives from FPGA to B4860. During power up or reset, the FPGA runs a state machine to control power sequence, and it contains PORESET output. So the PORESET driving time is constant everytime and this led "the HRESET asserting is about 4us prior to PORESET negation". I change the time setting in state machine when driving PORESET output, the time isnt 4us anymore, so this shouldnt be strange.

2) I change the DIP and make 4860 boot from NAND Flash, then I test the reset function(asserte PORESET) about 20 times, and every time is OK. It seems that B4860 can reset when booting from NAND Flash.

     I find a discussion in the community: linux hang on reboot b4860 ,it describes that when RCW is at NOR Flash, a hang may be observed when performing the reboot command at the kernel prompt.

     As we discussed, the reason lead to reset failed is likely to be an error occured during RCW reading/load, but when booting from NAND Flash, the failure doesnt present anymore. So I suspect that loading RCW from NOR Flash may occures error lead to the reset problem, is it right? And is there anyway can avoid that?

     Thank you!

[Bulat]

As per your waveforms the B5860 assert HRESET 4us prior to PORESET negation. Since PORESET is asynchronous input signal, the B4860 can not know when it will be negated. However in your case the B4860 somehow "knows" that PORESET will be negated and assert HRESET 4us before PORESET goes high. This is a bit strange assuming width of PORESET: about 400ms..  Note, minimum PORESET assertion time is 1ms, and HRESET will be asserted during this "short"  time.

As per your problem, I can advise following,

- check if RESET_REQ is not pulled low during PORESET;

- check that RCW is correctly loaded each time, included failed reset events;

- besides RESET_REQ, some other pins are required not to be pulled down during PORESET, these are IFC_A16...IFC_A20, IFC_WE, IFC_OE, IFC_WP0. Make sure that this requirement is met.

Regards,

Bulat

[weiwangw]

Thanks for your advice.

     I had measured several times, the HRESET asserting is about 4us prior to PORESET negation, no matter the reset process is successfully or failed.

     When reset failed, the RESET_REQ pulled low after PORESET negation. Here is the capture, yellow line is PORESET and pink line is RESET_REQ.

    

     Then, I tried to assert PORESET or HRESET to B4860 after RESET_REQ pulled low, but it didnt work.

     You suggest me "check that RCW is correctly loaded each time, included failed reset events", but when failed reset, I cant conncet the CodeWarrior TAP debugger to B4860 in CodeWarrior Development Studio(debug session chose download or attach). I think the 4860 had be halt, so do I have anyother way to check the RCW loading?

     Thank you!

[Bulat]

Your waveforms are very surprised, especially pink traces. Can you clarify how the 'pink' probe is connected? To which signal on the board? It does not correspond to normal HRESET behaviour on all traces. The processor asserts HRESET (low) much eariler than after PORESET deassertion.

Regards,

Bulat

[weiwangw]

Thanks Bulat,

     The pink probe connected to the HRESET of the chip.

     You said"The processor asserts HRESET (low) much eariler than after PORESET deassertion". I'm sorry for that, its because the time scale of oscilloscope maybe too large. I just set it 2us per grid, here is the picture.(yellow line is PORESET, pink line is HRESET)

1) B4860 reset successfully.(uboot mode)

2) B4860 reset failed.(enter Linux OS)

     a) 2us per grid:

     b)  2ms per grid:

     The Reference Manual indicate the chip run Power-On Reset Sequence failed led to HRESET not be deasserted. And, after enter Linux OS, I power down the chip(power down the Power Manager chip - 7304) then power up it, it also cant boot, the UART also have no output.

     I want to know what may cause this problem?

     Best regards.

[weiwangw]

I'm sure that PORESET is asserted at the B4860 during the reset process, it's PIN E1 in the picture blew.

And, here is the picture from oscilloscope when reset:

1) Press PORESET,  B4860 reset successfully. (yellow line is PORESET, pink line is HRESET)

here is the detial when PORESET deasserted.

2) Press PORESET,  B4860 reset failed. (yellow line is PORESET, pink line is HRESET)

here is the detial when PORESET deasserted, as we can see, the HRESET is always asserted.

Thank you!

[weiwangw]

Sorry for that, here is the detail in recent test:

1) When enter uBOOT after power on the board, the reset function is always OK. The chip can reset after asserting PORESET_B.

2) After enter Linux OS, the reset often dont work. We measured signals from FPGA, and found B4860 didnt negated the HRESET_B.(In B4860RM, HRESET_B is driven as an output during the first part of the power on reset sequence.)

3) Under normal condition, after reset (FPGA asserte PORESET_B), B4860 asserte HRESET_B for a while (about 50ms or less) and negate HRESET_B.

I want to know what may cause this, thanks.

[Bulat]

Actually it should not be important what kind of software is being executed when active PORESET applies. Are you absolutely sure that PORESET is asserted at the B4860 pin in item 2? Can you take PORESET and HRESET traces from an oscilloscope?

[Bulat]

Hello,

can you explain your problem better? You wrote "we met a problem when reseting the chip", what this really means? What exactly you are doing when resetting the chip?

Regards,

Bulat