----- Ursprüngliche Nachricht -----
Von: Wayne Uroda
Gesendet am: 30 Apr 2012 09:34:35

> The issue isn't with slow memory reads - the issue is with slow execution 
> after a call to MSP430_Run(RUN_TO_BREAKPOINT, 0); 
> which follows a memory read using  MSP430_Memory(...);

> For example, when starting GDB, GDB will halt the target, read the target 
> registers, then will read the word at the address of the 
program counter.
> This read will be accomplished with MSP430_Memory(....., READ); (using 
> MSPDebug with the tilib driver).

> Next in GDB if you enter the "continue" command, MSPDebug will call 
> MSP430_Run(RUN_TO_BREAKPOINT, 0);
> The target will free-run, however the execution speed is 10-12 times slower 
> than normal (running from DCO, I didn't test running from 
> a crystal - I am not sure if DCO is 
> just running slow or if it is being stopped periodically, I didn't check).

> I have confirmed that if the call to MSP430_Memory(....., READ); is 
> suppressed the target executes at the expected speed.
> I don't recall exactly but I think the slow speed persists until the target 
> is reset.

It looks like the library tries to halt the clocks ("freeze the time" for the 
MSP during the read access) and fails to undo this after the 
read.
Newer MSPs have additional functionality in teh EEM to stop the clocks during 
JTAG access, older don't. It could be that this new bug 
is a result of an attempt to emulate this clock stopping on older MSPs.
Can you simply check the content of the DCO configuration (DCOx, RSELx etc.) 
and the MCLK assignment before and after the 
memory read? Also, the read coul have cvaused an oscilaltor fault, MCLK 
fallback or something like that.
It's just guessing based on collected information pieces form the TI MSP and 
CCS forum.

JMGross


The problem can be easily seen with the latest GIT version of MSPDebug and 
msp430-gdb when used with the tilib driver and v3.2.3.15 
of MSP430.dll.

Thanks for looking into it.

- Wayne

-----Original Message-----
From: Stolyar, Rostyslav [mailto:r-stol...@ti.com] 
Sent: Monday, 30 April 2012 5:18 PM
To: Wayne Uroda; Daniel Beer; Wayne Uroda
Cc: mspgcc-users@lists.sourceforge.net
Subject: RE: [Mspgcc-users] Slow execution with MSPDebug, using tilib driver 
(msp430.dll v3)

Hi Wayne,

Thank you for your investigations. We'll check if there is a speed difference 
of the MSP430_Memory(....., READ) execution in the DLL 
v3.2.1.9 vs. v3.2.3.15.

Could you please tell me what the MSP430 device you have used? And memory range 
you have read out?

I'll come back in few days.

Regards,
Rosty



Texas Instruments Deutschland GmbH, Haggertystr. 1, D-85356 Freising. 
Amtsgericht M?nchen HRB 40960. Gesch?ftsf?hrer: Dr. 
Wolfram Tietscher. Vorsitzender des 
Aufsichtsrates: Edgar Frank

-----Original Message-----
From: Wayne Uroda [mailto:wayne.ur...@grabba.com]
Sent: Monday, April 30, 2012 1:52 AM
To: Daniel Beer; Wayne Uroda
Cc: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Slow execution with MSPDebug, using tilib driver 
(msp430.dll v3)

Hi,

I have updated to the latest GIT version of MSPDebug - it doesn't make any 
difference to the slow execution problem.

I have downgraded the MSP430.dll (and hil) to version 3.2.1.9 and the problem 
disappears, so by my reckoning the problem is 
definitely with v3.2.3.15 of MSP430.dll. (I 
have also replicated this on two machines and performed several firmware 
upgrades on the FET to confirm).

I hope this information is useful to somebody else when they are tearing their 
hair out in confusion.

- Wayne


-----Original Message-----
From: Daniel Beer [mailto:dlb...@gmail.com]
Sent: Monday, 30 April 2012 7:14 AM
To: Wayne Uroda
Cc: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Slow execution with MSPDebug, using tilib driver 
(msp430.dll v3)

At Sun, 29 Apr 2012 23:52:37 +1000, Wayne Uroda wrote:
> I have been doing a bit of work on MSPDebug over the weekend trying to
> figure out a few issues I've been having. The one problem I can't solve
> is when using msp430-gdb and mspdebug, the code executes about ten times
> slower than it should (when using the new tilib driver which makes use
> of TI's new MSP430.dll v3).
>
> During my testing I have determined that following a call to
> MSP430_Memory(....., READ); the execution speed will be slow. The first
> thing GDB does when connecting to the target is read the memory at the
> PC, which means it will always run slow after that. MSPDebug will run
> slow after the first run, ctrl+c combination, as it will read and
> disassemble the current function when you press ctrl+c.
>
> I am on windows 7 32bit using version 3.2.3.15 of msp430.dll (from
> msp430.dll_developer_package_rev_3.02.003.015.zip).
>
> I was wondering if anybody had run into similar issues? I will try
> duplicating the issue on my work PC tomorrow before I start making noise
> in the E2E forums.

Hi Wayne,

I've just fixed the bug you found with breakpoint handling. It might
be worth retesting with the latest git version, because this may be
related.

I would try reflashing your firmware before retesting. It looks like
gdb may have fallen back on its own software breakpoint implementation
due to the bug introduced by the latest breakpoint handling changes.

Cheers,
Daniel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Reply via email to