chip identity

[Nicola Perotto]

Hi all,
I want to identify a chip, U38 (from a Supermicro X5DPE-G2 mainboard).
Someone can help me?

The photo was taken with a Pentax Optio WG-1, a small waterproof camera with low
quality (tm) but an interesting feature: a microscope mode that combined with
the 5 white led let point and shoot at a pcb with good satisfaction!
The original photo and another one:
http://www.nicolaperotto.it/images/IMGP1056.JPG
http://www.nicolaperotto.it/images/IMGP1057.JPG
Thanks
        Nicola


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Yigit Turgut]

It's schottky diode, probably a variant of BAT45.

On Sun, Nov 6, 2011 at 8:05 PM, Nicola Perotto <[hidden email]> wrote:

> Hi all,
> I want to identify a chip, U38 (from a Supermicro X5DPE-G2 mainboard).
> Someone can help me?
>
> The photo was taken with a Pentax Optio WG-1, a small waterproof camera with
> low quality (tm) but an interesting feature: a microscope mode that combined
> with the 5 white led let point and shoot at a pcb with good satisfaction!
> The original photo and another one:
> http://www.nicolaperotto.it/images/IMGP1056.JPG
> http://www.nicolaperotto.it/images/IMGP1057.JPG
> Thanks
>       Nicola
>
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Nicola Perotto]

Reposting with [EE] tag also... sorry!

Hi all,
I want to identify a chip, U38 (from a Supermicro X5DPE-G2 mainboard).
Someone can help me?

The photo was taken with a Pentax Optio WG-1, a small waterproof camera with low
quality (tm) but an interesting feature: a microscope mode that combined with
the 5 white led let point and shoot at a pcb with good satisfaction!
The original photo and another one:
http://www.nicolaperotto.it/images/IMGP1056.JPG
http://www.nicolaperotto.it/images/IMGP1057.JPG
Thanks
         Nicola




--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[BT 4000]

Hi, I’m a long time lurker who until now had solved PIC problems by following threads and searching the archives but now I’m stumped. I have a PIC16F627 that is taking a Gramin RS232 stream, stripping out wanted data and then passing it on nibble-wise to an Arduino for logging to SD. The program runs for 5 cycles then stops, during these cycles the handshakes are fine and the nibbles past across are correct as observed on a digital analyser and the Garmin stream continues correctly. Loop 5 finishes correctly with all handshake lines low. Using a loop counter and a spare port pin I’ve identified the section of code where the program locks up/gets lost.
II’m at a total loss as to how to proceed further, any pointers will be gratefully received and please appreciate that this is a hobby project so don’t waste any precious time.
ZIP of program included
Mike

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Christopher Head-7]

On Sun, 14 Jun 2020 20:51:17 +0100
BT 4000 <[hidden email]> wrote:

> The program runs for 5 cycles then stops, during these
> cycles the handshakes are fine and the nibbles past across are
> correct as observed on a digital analyser and the Garmin stream
> continues correctly. Loop 5 finishes correctly with all handshake
> lines low.

What kind of programmer do you use? Does it have in-circuit debug
capabilities? Even the PICkit 3s do (maybe even the 2s, though I don’t
remember ever using it on them), and personally I find debugging tools
really helpful to look at how memory contents are evolving, see exactly
where execution got to, and that sort of thing. Given that you are
dealing with serial data arriving at a fixed speed, single-stepping
won’t really work too well, but at least you could stop the processor
after it gets into its failure state and look at exactly where the
program counter points, examine the register values to see if anything
looks unusual, and that sort of thing.
--
Christopher Head

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[BT 4000]

Thanks for lots of pointers, Sergio reminded me that bit manipulation of ports is very flaky, something I had forgotten, flashing diag-led now much better but hasn’t solved te problem
>
> What kind of programmer do you use? Does it have in-circuit debug
> capabilities?
Using a mish-mash of a 1990 tutorial/development board but having upgraded it with a PICkit3 this proggy doesn’t run on the board so I’ve bitten the bullet and put a PICit3 interface on the project pcb and am now fighting the MATLAB libraries as the Debugger is complaining.
I’m sure I’ll be back for more help, but for now it’s back to the manuals as it’s getting personal.
Mike


--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Richard Prosser]

Since it works OK at the start there would appear to be some sort of
resource limit being reached.
Is it possible that you're doing an RET, rather than a RETI (?) or
something similar that is causing stack or memory overwrite problems? Can
you monitor stack pointer position as well as a normally unused memory
location to get an idea as to what may be happening?

It's a long time since I used these devices, but I seem to remember
something similar happening to me at some stage & taking a while to track
down.

RP

On Thu, 18 Jun 2020 at 09:08, BT 4000 <[hidden email]> wrote:

> Thanks for lots of pointers, Sergio reminded me that bit manipulation of
> ports is very flaky, something I had forgotten, flashing diag-led now much
> better but hasn’t solved te problem
> >
> > What kind of programmer do you use? Does it have in-circuit debug
> > capabilities?
> Using a mish-mash of a 1990 tutorial/development board but having upgraded
> it with a PICkit3 this proggy doesn’t run on the board so I’ve bitten the
> bullet and put a PICit3 interface on the project pcb and am now fighting
> the MATLAB libraries as the Debugger is complaining.
> I’m sure I’ll be back for more help, but for now it’s back to the manuals
> as it’s getting personal.
> Mike
>
>
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[BT 4000]

Ok I regret to say I admit defeat, the 16F627 is not supported by the debugger in MPLAB X or 8.91 and PICkit3 is not supported in MPLAB 8.10,  so why am I using it?  After a long break from electronics due to eyesight problems the abundance of modules attracted me back and I rummaged in my ditty box and found these chips which were ideal for the task.
It’s a simple program so it was back to the bug chasing techniques I learnt on the Nascom 1 but now I have heavy assistance in the form of a Saleae logic analyser. So it runs for 5 loops, identifying one GPS message each loop, at the end of each loop, data valid is high then Data Read read goes high, 8usec later Data Valid goes low, 9usec later Data Read goes low then finally Data Ready goes low. But after loop 5 there are no further flag changes.
If I rem out the two references which test PORTA-2  eg
    btfss   PORTA,2 ;when BigBro has read the data A2 is set
    goto    ToBB2 ;wait for BigBro to read
and
    btfsc   PORTA,2 ;wait for BigBro to clear Read flag on A2
    goto    ToBB3
The program runs forever with the correct decoding and flags, if I uncomment just the first pair the program locks up as above.  I’ve sprayed NOPs liberally all around the loop with no effect apart from timing.
So I can’t see what else to do so I guess it’s move onto a supported chip and assume I found out why Microchip dropped this beast.
Thanks to all who provided help,  I certainly needed reminders on a few points
Mike
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[pp5ms]

Hi Mike,

Since I don’t know the rest of your code, it’s impossible to be able to give much help for sure.
What I can say is that the PIC16F627 is not to blame ... I used it a lot and the F628 without having any problems with them.
I noticed that your comment is that you need to waiting for the PORTA 2 to be set and after return to be clear.
The condition is being tested only the instant the PORTA,2 is tested and continues without returning to a new test.
Without knowing where "ToBB2" and "ToBB3" are, I can't say much.

To wait for the PORTA,2 to be set and then clear to follow, you can use this code:

         btfss        PORTA, 2        ; test if the data A2 is set
         goto         $ -1                 ; loop waiting for A2 became set
; and…
         btfsc        PORTA,2         ; test if the data A2 is clear
         goto        $-1                   ; loop waiting for A2 became clear

; program follow here….


Hope this can help.
Good look,
Marcus

> Em 22 de jun de 2020, à(s) 6:33 PM, BT 4000 <[hidden email]> escreveu:
>
> Ok I regret to say I admit defeat, the 16F627 is not supported by the debugger in MPLAB X or 8.91 and PICkit3 is not supported in MPLAB 8.10,  so why am I using it?  After a long break from electronics due to eyesight problems the abundance of modules attracted me back and I rummaged in my ditty box and found these chips which were ideal for the task.
> It’s a simple program so it was back to the bug chasing techniques I learnt on the Nascom 1 but now I have heavy assistance in the form of a Saleae logic analyser. So it runs for 5 loops, identifying one GPS message each loop, at the end of each loop, data valid is high then Data Read read goes high, 8usec later Data Valid goes low, 9usec later Data Read goes low then finally Data Ready goes low. But after loop 5 there are no further flag changes.
> If I rem out the two references which test PORTA-2  eg
>    btfss   PORTA,2 ;when BigBro has read the data A2 is set
>    goto    ToBB2 ;wait for BigBro to read
> and
>    btfsc   PORTA,2 ;wait for BigBro to clear Read flag on A2
>    goto    ToBB3
> The program runs forever with the correct decoding and flags, if I uncomment just the first pair the program locks up as above.  I’ve sprayed NOPs liberally all around the loop with no effect apart from timing.
> So I can’t see what else to do so I guess it’s move onto a supported chip and assume I found out why Microchip dropped this beast.
> Thanks to all who provided help,  I certainly needed reminders on a few points
> Mike
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Clint Jay]

Old chips need old tools, it's not a problematic chip, MChip will only have
dropped support because it's now considered obsolete.

So, you have a choice, if it's legacy code then I'd buy a PICKit2 clone or
maybe even a genuine new old stock one.

If it's new code, then I'd write off the 16F627 chips and just port it to a
newer chip that's supported.

Are you UK based?

On Mon, 22 Jun 2020 at 22:35, BT 4000 <[hidden email]> wrote:

> Ok I regret to say I admit defeat, the 16F627 is not supported by the
> debugger in MPLAB X or 8.91 and PICkit3 is not supported in MPLAB 8.10,  so
> why am I using it?  After a long break from electronics due to eyesight
> problems the abundance of modules attracted me back and I rummaged in my
> ditty box and found these chips which were ideal for the task.
> It’s a simple program so it was back to the bug chasing techniques I
> learnt on the Nascom 1 but now I have heavy assistance in the form of a
> Saleae logic analyser. So it runs for 5 loops, identifying one GPS message
> each loop, at the end of each loop, data valid is high then Data Read read
> goes high, 8usec later Data Valid goes low, 9usec later Data Read goes low
> then finally Data Ready goes low. But after loop 5 there are no further
> flag changes.
> If I rem out the two references which test PORTA-2  eg
>     btfss   PORTA,2     ;when BigBro has read the data A2 is set
>     goto    ToBB2       ;wait for BigBro to read
> and
>     btfsc   PORTA,2     ;wait for BigBro to clear Read flag on A2
>     goto    ToBB3
> The program runs forever with the correct decoding and flags, if I
> uncomment just the first pair the program locks up as above.  I’ve sprayed
> NOPs liberally all around the loop with no effect apart from timing.
> So I can’t see what else to do so I guess it’s move onto a supported chip
> and assume I found out why Microchip dropped this beast.
> Thanks to all who provided help,  I certainly needed reminders on a few
> points
> Mike
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
Clint. M0UAW IO83

*No trees were harmed in the sending of this mail. However, a large number
of electrons were greatly inconvenienced.*
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Mr Smiley]

Nascom, Z80, where did you use them ??

I still have some Nascom's here working with Zeap :o)

On 24/06/20 11:34, Clint Jay wrote:

> Old chips need old tools, it's not a problematic chip, MChip will only have
> dropped support because it's now considered obsolete.
>
> So, you have a choice, if it's legacy code then I'd buy a PICKit2 clone or
> maybe even a genuine new old stock one.
>
> If it's new code, then I'd write off the 16F627 chips and just port it to a
> newer chip that's supported.
>
> Are you UK based?
>
> On Mon, 22 Jun 2020 at 22:35, BT 4000 <[hidden email]> wrote:
>
>> Ok I regret to say I admit defeat, the 16F627 is not supported by the
>> debugger in MPLAB X or 8.91 and PICkit3 is not supported in MPLAB 8.10,  so
>> why am I using it?  After a long break from electronics due to eyesight
>> problems the abundance of modules attracted me back and I rummaged in my
>> ditty box and found these chips which were ideal for the task.
>> It’s a simple program so it was back to the bug chasing techniques I
>> learnt on the Nascom 1 but now I have heavy assistance in the form of a
>> Saleae logic analyser. So it runs for 5 loops, identifying one GPS message
>> each loop, at the end of each loop, data valid is high then Data Read read
>> goes high, 8usec later Data Valid goes low, 9usec later Data Read goes low
>> then finally Data Ready goes low. But after loop 5 there are no further
>> flag changes.
>> If I rem out the two references which test PORTA-2  eg
>>      btfss   PORTA,2     ;when BigBro has read the data A2 is set
>>      goto    ToBB2       ;wait for BigBro to read
>> and
>>      btfsc   PORTA,2     ;wait for BigBro to clear Read flag on A2
>>      goto    ToBB3
>> The program runs forever with the correct decoding and flags, if I
>> uncomment just the first pair the program locks up as above.  I’ve sprayed
>> NOPs liberally all around the loop with no effect apart from timing.
>> So I can’t see what else to do so I guess it’s move onto a supported chip
>> and assume I found out why Microchip dropped this beast.
>> Thanks to all who provided help,  I certainly needed reminders on a few
>> points
>> Mike
>> --
>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>>
>

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Harold Hallikainen-3]

I have not seen my replies show up on the list, and I've been haqving
problems with outgoing mail. I suspect the issue is with the goto
statements. If they cross page boundaries, PCLATH needs to be loaded with
the high part of the destination address.

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com
Not sent from an iPhone.
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[sergio]

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Forrest Christian (List Account)]

Went digging on the debug thing...

Looks like these are some of the chips which you had to buy a special
version of the chip and/or a debug header to debug.  From the datasheet of
the 'A' variant:

" Since in-circuit debugging requires the loss of clock, data and MCLR
pins, MPLAB® ICD 2 development with an 18-pin device is not practical. A
special 28-pin PIC16F648A-ICD device is used with MPLAB ICD 2 to provide
separate clock, data and MCLR pins and frees all normally available pins to
the user. Debugging of all three versions of the PIC16F627A/628A/648A is
supported by the PIC16F648A-ICD."

It appears that the Non-A might even be more restrictive.  Hard to tell
from the datasheet.



On Wed, Jun 24, 2020 at 4:44 AM Clint Jay <[hidden email]> wrote:

> Old chips need old tools, it's not a problematic chip, MChip will only have
> dropped support because it's now considered obsolete.
>
> So, you have a choice, if it's legacy code then I'd buy a PICKit2 clone or
> maybe even a genuine new old stock one.
>
> If it's new code, then I'd write off the 16F627 chips and just port it to a
> newer chip that's supported.
>
> Are you UK based?
>
> On Mon, 22 Jun 2020 at 22:35, BT 4000 <[hidden email]> wrote:
>
> > Ok I regret to say I admit defeat, the 16F627 is not supported by the
> > debugger in MPLAB X or 8.91 and PICkit3 is not supported in MPLAB 8.10,
> so
> > why am I using it?  After a long break from electronics due to eyesight
> > problems the abundance of modules attracted me back and I rummaged in my
> > ditty box and found these chips which were ideal for the task.
> > It’s a simple program so it was back to the bug chasing techniques I
> > learnt on the Nascom 1 but now I have heavy assistance in the form of a
> > Saleae logic analyser. So it runs for 5 loops, identifying one GPS
> message
> > each loop, at the end of each loop, data valid is high then Data Read
> read
> > goes high, 8usec later Data Valid goes low, 9usec later Data Read goes
> low
> > then finally Data Ready goes low. But after loop 5 there are no further
> > flag changes.
> > If I rem out the two references which test PORTA-2  eg
> >     btfss   PORTA,2     ;when BigBro has read the data A2 is set
> >     goto    ToBB2       ;wait for BigBro to read
> > and
> >     btfsc   PORTA,2     ;wait for BigBro to clear Read flag on A2
> >     goto    ToBB3
> > The program runs forever with the correct decoding and flags, if I
> > uncomment just the first pair the program locks up as above.  I’ve
> sprayed
> > NOPs liberally all around the loop with no effect apart from timing.
> > So I can’t see what else to do so I guess it’s move onto a supported chip
> > and assume I found out why Microchip dropped this beast.
> > Thanks to all who provided help,  I certainly needed reminders on a few
> > points
> > Mike
> > --
> > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
> >
>
>
> --
> Clint. M0UAW IO83
>
> *No trees were harmed in the sending of this mail. However, a large number
> of electrons were greatly inconvenienced.*
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
- Forrest
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[BT 4000]

I’d like to thank all for the response especially Sergio. Gave me a good kick up the rear and I managed to get a logical response out of the beast.  Changing a few lines showed that the Read handshake was somehow being generated by the PIC and not the Arduino.  The Arduido was taking far longer to settle so the first 4 loops were pure PIC!  At this point my cct decided to start killing the 627s - device not recognised - after three chips I’m down to my last one so I’m saving that until I have a working program I WILL return.  Meantime the proggy is being ported to a PIC16F18346 which I can play with on the Explorer 8.
I should mention that as a recent joining member of the Cyclops club my soldering has gone from ‘old school average’ to diabolical
Mike
 


--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Harold Hallikainen-3]

So there was no problem with the goto without making sure PCLATH was
properly set for the destination?

Harold

> I’d like to thank all for the response especially Sergio. Gave me a good
> kick up the rear and I managed to get a logical response out of the beast.
>  Changing a few lines showed that the Read handshake was somehow being
> generated by the PIC and not the Arduino.  The Arduido was taking far
> longer to settle so the first 4 loops were pure PIC!  At this point my cct
> decided to start killing the 627s - device not recognised - after three
> chips I’m down to my last one so I’m saving that until I have a
> working program I WILL return.  Meantime the proggy is being ported to a
> PIC16F18346 which I can play with on the Explorer 8.
> I should mention that as a recent joining member of the Cyclops club my
> soldering has gone from ‘old school average’ to diabolical
> Mike
>
>
>
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
FCC Rules Updated Daily at http://www.hallikainen.com
Not sent from an iPhone.
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist