Recent Posts

1

Microcontrollers / Re: Looking for help to debug 32F4 ethernet

« Last post by peter-h on Today at 03:24:02 pm »

I've fixed it, by stepping back through previous versions. Can anyone see a problem with this linkfile syntax? The purpose is to first collect DATA from the 1st module (main.o) and then collect DATA from the remaining modules. There is no particular reason for doing that other than it is neater in the .map file

Code: [Select]


/* Initialized data sections for non boot block code. These go into RAM. LMA copy is loaded after code. */
/* This stuff is copied from FLASH to RAM by C code in the main stub */
/* This is stuff like int fred = 1; which is copied flash -> ram (not const) */

. = ALIGN(4);

/* main.c DATA */
  .main_data :
  {
    . = ALIGN(4);
    _s_nonboot_data = .;        /* create a global symbol at data start */
    *main.o (.data .data*)      /* .data sections */
    . = ALIGN(4);
  } >RAM  AT >FLASH_APP

/* Remaining DATA */
._other_data :
  {
    . = ALIGN(4);
    *(.data .data*)      /* .data sections */
      . = ALIGN(4);
    _e_nonboot_data = .;        /* define a global symbol at data end */
  } >RAM  AT >FLASH_APP

  /* used by the main stub C code to initialize data */
  _si_nonboot_data = LOADADDR(.KDE_main_data);


Previously it was done all in one go and that works fine

Code: [Select]


.all_nonboot_data :
  {
    . = ALIGN(4);
    _s_nonboot_data = .;        /* create a global symbol at data start */
    *(.data .data*)      /* .data sections */
      . = ALIGN(4);
    _e_nonboot_data = .;        /* define a global symbol at data end */
  } >RAM  AT >FLASH_APP

  /* used by the main stub C code to initialize data */
  _si_nonboot_data = LOADADDR(.all_nonboot_data);

Obviously it would be good to know what the problem is in the first one, but the linkfile syntax is horrible and there is no useful error reporting; you just get a line # because real men don't need anything else

I did always suspect the issue was with DATA not getting initialised correctly in RAM from its FLASH image.

2

Programming / Re: Github: when deleted is not deleted and private not private

« Last post by Siwastaja on Today at 03:22:18 pm »

Read halfway through it. Some idiotic sensationalism, is there finally some real problem?

What blast from the past. So someone accidentally posted their private key / password / titpic / dickpic publicly on the internets and someone else took a copy (or "forked") it before they could delete it. What are you supposed to do as service provider? Yellow media and concerned citizens demanded censorship of the Internet and other totally impractical measures to somehow prevent this mistake. This was in early 2000's. We learned back then there is no other way than never do this mistake; and if you do, you suffer.

Now even normal people have pretty much understood not to post sensitive information publicly on the internet (and be very careful where to post it), and have stopped blaming others for their own mistakes. Is it too much to expect from freaking programmers to do the same?

3

Test Equipment / Re: Hp 54501a worth grabbing?

« Last post by TomKatt on Today at 03:19:45 pm »

BIG difference between 15KHz and 15MHz…

4

RF, Microwave, Ham Radio / Re: 153-279kHz LW radio to receive 15-150kHz ultrasounds

« Last post by wofritz on Today at 03:16:19 pm »

I read your other thread and wondered if one of the relatively cheap SDRs like the SDRPlay RSP1 could be used. The RSP1A goes down to 5 kHz.

Since these are software  defined radios, you need software running on some computing device which could make portable operation a bit cumbersome. I don't know if there is any SDR software running on mobile devices  like phones or tablets.

These RSP1A can receive a wide frequency range simultaneously, so 5 kHz to 150 kHz is no problem. You can monitor the whole spectrum on the screen.

I have such an SDR running but I have no frontend (microphone and maybe preamplifier) to receive sound but I would really like to test it because I think there are bats flying around my house.

5

Repair / Re: Acer XB321HK monitor power board voltage issues?

« Last post by Tim88 on Today at 03:10:39 pm »

I do have a scope, what do you want to see?

6

Repair / Re: Acer XB321HK monitor power board voltage issues?

« Last post by Tim88 on Today at 03:07:59 pm »

Measure 2.49V so am assuming we are good on the low voltage side.

7

Repair / Re: Acer XB321HK monitor power board voltage issues?

« Last post by Tim88 on Today at 03:06:19 pm »

Hi, thanks for the response. My thoughts were also on the regulation side. That 4870 and 18700 I cannot confirm without removing, may have to do that, they are those tiny SMD (I hate those). I measured the ref pin on the TL431 and it is 2.49V on the button. Maybe the optocoupler may not be conducting? I wish I could identify where the smoke was coming from, so many soot tattoos on the shielding. As for the 12V output, steady should have been used, not solid. No fluctuation on the voltage. Will look into how to verify the optocoupler is working. 

8

Microcontrollers / Re: XMEGA32A4 - Monitoring RX TX - Extracting or flashing firmwar

« Last post by Tantratron on Today at 02:57:50 pm »

Ok many thanks Tim where I've checked now with lens and concentration the traces in that zoning, so indeed the test points TP16 and TP17 are for PDI (Programming Debugging Interface) as you taught me.

As for the RX-out (orange wire) and TX-in (blue wire), they are respectively connected via some passive components to PD3 and PD2 of the XMEGA32A4..

So whatever I could expect to say extract or read the firmware, it will be only through TP16 and TP17.

I'll first try to use my SALEAE Logic analyzer to observe RX=TX sequence then what happens when RX and TX not connected.

Albert

9

3D printing / Re: Filament storage bags

« Last post by wraper on Today at 02:55:52 pm »

^Waste of money. For this price you can buy real moisture barrier bags and much larger pouches of silica gel which will keep filament dry for years, and will have some money left.

10

Microcontrollers / Re: XMEGA32A4 - Monitoring RX TX - Extracting or flashing firmwar

« Last post by T3sl4co1l on Today at 02:51:35 pm »

You must've missed why I circled the pads in the image.  If you read the device datasheet (linked), you will find the chip uses the "PDI" protocol for programming.  You need only connect these pins to a programming adapter to further investigate the device.

What method you use to obtain such a programmer, is up to you. Perhaps there is an Arduino version you can use with your board, if you must.  Most likely you will need the AVRDUDE tool as well.

Again, regarding your question: it is impossible to know whether it is feasible.  It might be trivial, or it might be physically impossible.  I doubt AVRs are so secure for the latter to be true, but proving so is a very different matter.

The most basic start would be probing with an oscilloscope or logic analyzer.

Tim