[Freetel-codec2] Another item for the PCB TO-DO List: nJRST pin

[Stuart Longland]

Hi all,

Here's something we should add to the PCB for the next SM1000 revision,
a pin for nJRST.

https://sourceforge.net/p/openocd/mailman/message/32108017/

Presently, due to that erratum, the only way to flash a SM1000 is using
dfu-util, and I'm finding that it might take as many as 5 or 10 attempts
of power cycling and pressing PTT in to get it into DFU mode.

[David Rowe]

Hi Stuart,

The link seems to refer to flashing via STLINK - the 3 pin debug connector.

I have used STLINK to flash SM1000s many times during development -
using just the 3 pins on CN1. This include 405 and 407 devices. I used
a Discovery Board as the emulator "pod".

I'm not familiar with the nJRST pin on the uC, can you pls describe
exactly what connection you would like to see (i.e. pin numbers, where
the net would be routed to)?

We have provision for a reset button SW5 (nRST pin 14 on the uC) on the
SM1000 which I found handy during development when I was flashing via
STLINK.

I have found DFU mode comes up immediately every time, by holding PTT
down as the SM1000 is switched on. I just tried again on a new SM1000
and 5/5 times on first press. Perhaps you have a hardware fault?
Cables? Contact me off list if you think its the SM1000 hardware.

- David

Post by Stuart Longland
Hi all,
Here's something we should add to the PCB for the next SM1000 revision,
a pin for nJRST.
https://sourceforge.net/p/openocd/mailman/message/32108017/
Presently, due to that erratum, the only way to flash a SM1000 is using
dfu-util, and I'm finding that it might take as many as 5 or 10 attempts
of power cycling and pressing PTT in to get it into DFU mode.

[Stuart Longland]

Post by David Rowe
The link seems to refer to flashing via STLINK - the 3 pin debug connector.
I have used STLINK to flash SM1000s many times during development -
using just the 3 pins on CN1. This include 405 and 407 devices. I used
a Discovery Board as the emulator "pod".

Interesting, wonder what I'm doing wrong then. I'm using an actual
STLink/V2 programmer device, which seems to work fine for actually
debugging the SM1000, just not programming it.

Post by David Rowe
I'm not familiar with the nJRST pin on the uC, can you pls describe
exactly what connection you would like to see (i.e. pin numbers, where
the net would be routed to)?

My apologies, it's called nJTRST; pin 90. It otherwise is known as PB4.

Post by David Rowe
We have provision for a reset button SW5 (nRST pin 14 on the uC) on the
SM1000 which I found handy during development when I was flashing via
STLINK.

Ahh, wondered what that button did. Didn't seem to do anything though.

Post by David Rowe
I have found DFU mode comes up immediately every time, by holding PTT
down as the SM1000 is switched on. I just tried again on a new SM1000
and 5/5 times on first press. Perhaps you have a hardware fault?
Cables? Contact me off list if you think its the SM1000 hardware.

Interesting, not sure what's going on then.

The set-up here:
- SM1000 has case open
- STLink/V2 plugged into CN1
- my laptop (late 2008 Apple MacBook) plugged into "RIG SPKR"
- an old pair of headphones (70's era paper cone ones) plugged into EXT SPKR
- Power from 100Ah 12V AGM battery

Some theories I'm thinking of:
- Switch bounce? Maybe I'm not doing it right and there's just a little
contact bounce as I'm holding it.
- RFI? Here at The Gap, I'm practically in the shadow of Mt. Coot-tha,
where there exists many high-power VHF and UHF transmitters for the
local television and radio stations.

Anyway, currently I've been attempting to get the speech prompts
working. I note that the SM1000 here fails to pass through analogue or
decode FreeDV 1600 since around revision 2482 (according to `git
bisect`) and I'm just trying to figure out why.

[Stuart Longland]

Post by Stuart Longland
- Switch bounce? Maybe I'm not doing it right and there's just a little
contact bounce as I'm holding it.
- RFI? Here at The Gap, I'm practically in the shadow of Mt. Coot-tha,
where there exists many high-power VHF and UHF transmitters for the
local television and radio stations.

Okay, add another theory:
- ambient temperature

I'm working on the back deck where there's plenty of light, space, and
there's the odd breeze to keep things cool.

It got to 30.8°C today, and it's now 25.5°C. I'm able to bring it in
and out of DFU mode reliably now, whereas before it would take between 2
and 10 attempts (seemingly random). It's like the little STM32 wants to
taunt me. ;-)

[glen english]

My practical experience (20+ designed) with the JRST pin is you should
leave it unconnected or pulled.

Post by David Rowe
Hi Stuart,
The link seems to refer to flashing via STLINK - the 3 pin debug connector.
I have used STLINK to flash SM1000s many times during development -
using just the 3 pins on CN1. This include 405 and 407 devices. I used
a Discovery Board as the emulator "pod".
I'm not familiar with the nJRST pin on the uC, can you pls describe
exactly what connection you would like to see (i.e. pin numbers, where
the net would be routed to)?
We have provision for a reset button SW5 (nRST pin 14 on the uC) on the
SM1000 which I found handy during development when I was flashing via
STLINK.
I have found DFU mode comes up immediately every time, by holding PTT
down as the SM1000 is switched on. I just tried again on a new SM1000
and 5/5 times on first press. Perhaps you have a hardware fault?
Cables? Contact me off list if you think its the SM1000 hardware.
- David

Post by Stuart Longland
Hi all,
Here's something we should add to the PCB for the next SM1000 revision,
a pin for nJRST.
https://sourceforge.net/p/openocd/mailman/message/32108017/
Presently, due to that erratum, the only way to flash a SM1000 is using
dfu-util, and I'm finding that it might take as many as 5 or 10 attempts
of power cycling and pressing PTT in to get it into DFU mode.

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

--
-
Glen English
RF Communications and Electronics Engineer

CORTEX RF
&
Pacific Media Technologies Pty Ltd

ABN 40 075 532 008

PO Box 5231 Lyneham ACT 2602, Australia.
au mobile : [phone]

[Stuart Longland]

Post by glen english
My practical experience (20+ designed) with the JRST pin is you should
leave it unconnected or pulled.

Well, I only put the idea forward because when I did a search for what
caused the error I was getting, there was mention of an erratum item
regarding the STM32F4 in the post I linked to. The post seemed to
describe the symptoms I was seeing.

The fact that David's had success using the STM32F4 Discovery board as a
SWD programmer to program SM1000 boards suggests something else might be
the matter at my end. Probably the same reason I have trouble invoking
the DFU bootloader.

I would definitely agree that it should be pulled up to Vcc.