error in running sc-experiment about screaming_channels HOT 26 CLOSED

Hello,

It looks like an error due to the wrong version of click, sorry for not having specified it in the setup.py
Could you please try with this version I attach below and tell me if solves your problem?

Best,
Giovanni

from setuptools import setup, find_packages

setup(
    name="ScreamingChannels",
    version="1.0",
    packages=find_packages(),
    python_requires=">=2.7,!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*",
    entry_points={
        "console_scripts": [
            "sc-experiment = screamingchannels.reproduce:cli",
            "sc-attack = screamingchannels.attack:cli",
        ]
    },
    install_requires=[
        "click==6.7",
        "numpy",
        "scipy==1.1.0",
        "pyserial",
        "matplotlib==2.2.3",
        "enum34",
        "pmt"

# to use system packages
#        ln -s /usr/lib/python2.7/site-packages/gnuradio ../../../../screaming-channel/nRF52832/experiments/VENV_sc/lib/python2.7/site-packages
#        "gnuradio",
#        "osmosdr",
    ],

    author="S3@EURECOM",
    author_email="[email protected], [email protected], [email protected]",
    description="Code for our screaming channel attacks",
    license="GNU General Public License v3.0"
)

from screaming_channels.

Hi,

Thanks for the solution. I tried with installing these specific packages and now I am able to run sc-experiment. But when I tried to run the command:

sc-experiment --radio=HackRF --device=/dev/ttyACM0 collect config/example_collection_plot.json ../traces/example_collection_data --plot

it displayed an error that it is unable to find the USRP device. So , I made changes in the USRP device address in the reproduce.py because I am using a B210 which does not connects with the network so it only has a serial address.

These are the changes I made:

class GNUradio(gr.top_block):
"""GNUradio capture from SDR to file."""
print "hello0\n"
print "hello2\n"
radio_block = uhd.usrp_source(
#("addr=" + RADIO_ADDRESS.encode("ascii"))
("serial=30ECB6C")# + RADIO_ADDRESS.encode("ascii"))
if RADIO == Radio.USRP else "",
uhd.stream_args(cpu_format="fc32", channels=[0]))
radio_block.set_center_freq(frequency)
radio_block.set_samp_rate(sampling_rate)
radio_block.set_gain(40)
radio_block.set_antenna("TX/RX")

self._file_sink = blocks.file_sink(gr.sizeof_gr_complex, OUTFILE)
self.connect((radio_block, 0), (self._file_sink, 0))

But now I am getting some new errors given as below:

mtlab@mtlab:~/nordic/screaming_channels-master/experiments/src/screamingchannels$ sudo python2.7 /home/mtlab/.local/bin/sc-experiment --radio=USRP --device=/dev/ttyACM1 collect /home/mtlab/nordic/screaming_channels-master/experiments/config/example_collection_plot.json ~/nordic/screaming_channels-master/experiments/traces/ --plot
[sudo] password for mtlab:
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown

[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; UHD_3.11.0.HEAD-0-ga1b5c4ae
[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 2.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
Traceback (most recent call last):
File "/home/mtlab/.local/bin/sc-experiment", line 11, in
load_entry_point('ScreamingChannels==1.0', 'console_scripts', 'sc-experiment')()
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 480, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 2693, in load_entry_point
return ep.load()
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 2324, in load
return self.resolve()
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 2330, in resolve
module = import(self.module_name, fromlist=['name'], level=0)
File "/home/mtlab/.local/lib/python2.7/site-packages/ScreamingChannels-1.0-py2.7.egg/screamingchannels/reproduce.py", line 469, in
class GNUradio(gr.top_block):
File "/home/mtlab/.local/lib/python2.7/site-packages/ScreamingChannels-1.0-py2.7.egg/screamingchannels/reproduce.py", line 478, in GNUradio
radio_block.set_center_freq(frequency)
NameError: name 'frequency' is not defined

Please guide further.

from screaming_channels.

Hello,

The 'frequency' variable is given as a parameter of the constructor, and it should work without any changes, but I do not see the constructor anymore in the code you pasted.

I just recently received a B210, so I tried it.
After using uhd_find_devices to make sure my B210 is visible, I have just run the non modified code with the option --radio USRP_mini and it worked.
Adjust the arguments (antenna, gain, etc.) according to your needs.

Unrelated: you can add udev rules for the NLENano device so that you do not need to run with sudo.

Best,
Giovanni

from screaming_channels.

Hello,

I have now undone all the changes to the reproduce.py to the original and now I am trying to run sc-experiment as follows:

mtlab@mtlab:~/nordic/screaming_channels-master/experiments$ sc-experiment --radio=USRP_mini --device=/dev/ttyACM0 collect config/example_collection_plot.json /home/mtlab/nordic/screaming_channels-master/experiments/src/traces/example_collection_data --plot
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown

but it doesn't show any outputs and nor does it stops.

What's missing now? Please guide further.

from screaming_channels.

Hello,

Here is my guess on your problem.
The protocol that talks with the target device is stateful, so if the collection fails it may stay in a state different than the initial one, and make the next run stuck.

I believe your device entered in tinyaes mode because of a previous run, but it never exited because the run failed.

You can manually connect to the device and press 'q' to exit the mode after a crash. Alternatively, if you plug the target to a ykush, there is an option to automatically reset it before each collection.

Best,
Giovanni

from screaming_channels.

Hi,

Yes, you are right. I checked this running the chip multiple times and it ran correctly only once and gave the plot.
Everytime I run the sc-experiment , the chip goes into the tiny_aes mode and it is stuck there in the first cycle only. And then I have to open another terminal with minicom to pass 'q' to exit the tiny_aes mode.

Is there any solution other than 'ykush' by which we can pass 'q' to the chip so that it can we get same results everytime?

(Nerdy mind : I was thinking to make some changes in the "main.c", "aes.c" and "reproduce.py". Will that help in any manner?).

from screaming_channels.

Hi,

You need a good configuration/tuning to have the code running properly and extract the traces. The one I provide works quite well with my radios and my settings, but maybe we need some adjustment for your case. Each parameter and the procedure are explained in the README. I will be happy to help if you give me more information on the errors and problems you encounter, so that I can guide you to the right parameter to tune. To start, try to reduce drop_start and increase the number of traces per point, to be sure you do not cut useful data.

You could try to make reproduce.py catch the error and send 'q' and 'e' at that moment the error occurs. Another quick and dirty option is to send 'q' and 'e' just before collection.

Giovanni

from screaming_channels.

P.S.

I just tried this configuration with a B210, a WiFi antenna, at 10cm from the target.
I paste it here so that you can try it.

You can also edit the sleep after gnuradio.start() from 0.03 to 0.11.

{
"firmware": {
"mode": "tinyaes",
"fixed_key": false,
"modulate": true
},
"collection": {
"target_freq": 2.528e9,
"sampling_rate": 5e6,
"num_points": 1,
"num_traces_per_point": 100,
"bandpass_lower": 1.95e6,
"bandpass_upper": 2.02e6,
"lowpass_freq": 5e3,
"drop_start": 10e-3,
"trigger_rising": true,
"trigger_offset": 100e-6,
"signal_length": 300e-6,
"template_name": "templates/tiny_anechoic_10m_080618.npy",
"min_correlation": 0.00,
}
}

Best,
Giovanni

from screaming_channels.

Hello,
Thanks for the code. It is working for my setup too.
But I am unable to collect my own traces (more than 10000) for attack in a desired folder. Tell me how to do that. I am not getting what arguments to pass with sc-experiment in order to save my own collection of trace.
I tried running sc-attack with your pre-collected traces and the attack works well.

I am using a B210 with near field Langer Probes: EMV and RF-R 400-1 with distance less than 1 cm. Also for attack at 3m I am using the generic NooElec Antenna which comes with the Nooelec DVB stick.
Please ask for any more information you require if I have not mentioned here.

Thanks

Regards,
Ateet

from screaming_channels.

Hello,

Great collection is starting to work well.
Say you have created a folder named /home/ateet/myfolder,
then you can save the collected traces there by passing the path as second parameter to the collect command, e.g.:
sc-experiment --radio=USRP --device=/dev/ttyACM0 collect myconfig.json /home/ateet/myfolder

Best,
Giovanni

from screaming_channels.

Here is the output I get:

TX modulated carrier

Entering tiny_aes_128 mode

Setting number of repetitions to 240

[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; UHD_3.11.0.HEAD-0-ga1b5c4ae
[INFO] [B200] Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex...
[INFO] [B200] Detected Device: B210
[INFO] [B200] Loading FPGA image: /usr/local/share/uhd/images/usrp_b210_fpga.bin...
[INFO] [B200] Operating over USB 2.
[INFO] [B200] Detecting internal GPSDO....
[INFO] [GPS] No GPSDO found
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [B200] Asking for clock rate 40.000000 MHz...
[INFO] [B200] Actually got clock rate 40.000000 MHz.
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[------------------------------------] 1%

It doesn't move further from 1% and even after getting the plot it doesn't stops on the terminal.

What does the number of repetition actually depicts here? Because I am not able to increase it beyond 240 don't know why.

Also I checked the folder in which I am trying to save the traces, it only has the key and plaintext file, but no trace file is there.

from screaming_channels.

There are two parameters in the configuration, num_points (the number of traces you want to collect) an d num_traces_per_point (each trace is actually the average of many traces). Repetitions refers to num_traces_per_point.

So, say you want to collect 1000 traces, each made of the average of 500 traces, you will set num_points to 1000 and num_traces_per_point to 500 (this is usually a good tradeoff).

As explained here, when the num_traces_per_point becomes too big, the plot may ask to many resources to work. For safety, we put an assertion that limits the number of num_traces_per_point in case the plot option is on.

In general, use th plot option only with num_points equal to 1 and num_traces_per_point small e.g. 100. Once you see that the extraction goes well, you can increase those numbers, and run the collection without plotting.

I guess in your case the code is stuck plotting the second acquisition, simply try to disable the plot option.

from screaming_channels.

from screaming_channels.

Hi,

Can you tell me the meaning of this output?

linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown

TX modulated carrier

Entering tiny_aes_128 mode

Setting number of repetitions to 12

[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; UHD_3.11.0.HEAD-0-ga1b5c4ae
[INFO] [B200] Detected Device: B210
[INFO] [B200] Operating over USB 2.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz...
[INFO] [B200] Actually got clock rate 16.000000 MHz.
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [B200] Asking for clock rate 40.000000 MHz...
[INFO] [B200] Actually got clock rate 40.000000 MHz.
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[####################################] 100%Extracted
Number = 9
avg[Max(std)] = 2.01E-02
Max(u) = Max(std) = 1.03E-02
Max(u_rel) = 5.15E+01 %

Done

Also, I am still getting only one trace file named "avg_0.npy" in the folder and one key and plaintext file each.

from screaming_channels.

I want to collect some 'n'-thousands aes traces in different trace files having one trace each. And then I will mount the attack on these traces using sc-attack. This is what I exactly want to do.

Please tell me where do I need to make changes and in which files.

Thanks in advance

Regards
Ateet

from screaming_channels.

Hello,

There are three important parameters in the config file: "num_points", "num_traces_per_point", and "fixed_key".
The collection tool will do the following (pseudocode)

generate num_points different random plaintexts
if fixed_key == True:
     generate num_points times the same random key
else:
     generate num_points different random keys

for i in 0 to num_points:
    for j in 0 to num_traces_per_point:
        encrypt(plaintexts[i], keys[i])
    extract num_traces_per_point encryption traces
    average them to obtain a single less noisy trace
    save it as avg__$i.npy

So, I guess you may want to do the following:
"num_points" : 10000
"num_traces_per_point": 500
"fixed_key: true (for attack) or false (for template)

This will generate 10000 files called avg__0.npy, avg__1.npy, ... avg_9999.npy. Each of them will contain 1 trace which is the average of 500 encryptions.

Now I can also answer to the first question. What you are doing there is to set num_points to 1, this is why you get only one file named avg__0.npy containing only one trace.
The numbers at the end are some stats on the extracted traces before averaging to give an idea of the noise level. One more detail is that depending on the configuration, you may end up extracting less traces that "num_traces_per_point" (e.g., because the "drop_start" is too big), this is why in your case you extract only 9 traces before average. Besides playing with "drop_start", you could also play with the sleep times inside reproduce.py., etc.

There are much more details about collection that could be useful, you can find a full explanation and tutorial here for reference.

Hope this helps.

Best,
Giovanni

from screaming_channels.

Hi,
Thank you for replying.
Yes, this helped a lot.

So, now I tried with the following parameters:

    "firmware": {
        "mode": "tinyaes",
        "fixed_key": true,
        "modulate": true
    },
    "collection": {
        "target_freq": 2.528e9,
        "sampling_rate": 5e6,
        "num_points": 2,
        "num_traces_per_point": 100,
        "bandpass_lower": 1.85e6,
        "bandpass_upper": 1.95e6,
        "lowpass_freq": 5e3,
        "drop_start": 50e-3,
        "trigger_rising": true,
        "trigger_offset": 100e-6,
        "signal_length": 300e-6,
        "template_name": "",
        "min_correlation": 0.00
    }
}

Now, I get the plot for 1st repetition i.e. 50% process, but after plotting the graph the program stops there and waits indefinitely.

If I don't plot the graph and run without --plot it shows the following output:

  [##################------------------]   50%Extracted 
Number =  98
avg[Max(std)] = 2.15E-02
Max(u) = Max(std) = 7.82E-03
Max(u_rel) = 3.63E+01 %
  [####################################]  100%
Traceback (most recent call last):
  File "/home/mtlab/.local/bin/sc-experiment", line 11, in <module>
    load_entry_point('ScreamingChannels==1.0', 'console_scripts', 'sc-experiment')()
  File "/home/mtlab/.local/lib/python2.7/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/home/mtlab/.local/lib/python2.7/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/home/mtlab/.local/lib/python2.7/site-packages/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/mtlab/.local/lib/python2.7/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/mtlab/.local/lib/python2.7/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/home/mtlab/.local/lib/python2.7/site-packages/ScreamingChannels-1.0-py2.7.egg/screamingchannels/reproduce.py", line 356, in collect
    _send_plaintext(ser, plaintext)
  File "/home/mtlab/.local/lib/python2.7/site-packages/ScreamingChannels-1.0-py2.7.egg/screamingchannels/reproduce.py", line 230, in _send_plaintext
    _send_parameter(ser, 'p', plaintext)
  File "/home/mtlab/.local/lib/python2.7/site-packages/ScreamingChannels-1.0-py2.7.egg/screamingchannels/reproduce.py", line 213, in _send_parameter
    check = ''.join(chr(int(word)) for word in ser.readline().split(' '))
  File "/home/mtlab/.local/lib/python2.7/site-packages/ScreamingChannels-1.0-py2.7.egg/screamingchannels/reproduce.py", line 213, in <genexpr>
    check = ''.join(chr(int(word)) for word in ser.readline().split(' '))
ValueError: invalid literal for int() with base 10: 'Done\r\n'

I guess this is still because of the "drop-start" value and the "time.sleep()" values.

The file reproduce.py has sleep time at many places. Can you please tell me line numbers where it is needed to be changed?

from screaming_channels.

And please have a look at this snippet of the reproduce.py . I think it is appending the same trace file. There shall be a loop till running "num_points" .

Thanks a lot
Regards
Ateet

from screaming_channels.

The error is in the protocol exchange, the program receives a "Done" message, but it is expecting an integer. Let me check the reason and I will come back to you, in the meanwhile can you reset the board and rerun (without plot)?

from screaming_channels.

I have double checked and run the collection code, everything is fine on my side, I do not see any error in the protocol due to the code.
Does resetting the board clean the state and make the next collection work?

Regarding the sleeps:
line 359: sleep to give some time to gnuradio to start before starting encryptions. Increase it if the encryptions start too early compared to the collection and you miss some.
You may as well want to add a short sleep at line 370 at the same indentation as gnuradio stop, to give some time to gnuradio to collect and process the data before stopping it.

from screaming_channels.

Hi,
Thank you for replying.

I tried all the suggestions you told.

It is showing the same error everytime I try to collect more than one trace, even without the --plot.

  [------------------------------------]    0%Extracted 
Number =  100
avg[Max(std)] = 1.31E-02
Max(u) = Max(std) = 6.16E-03
Max(u_rel) = 4.72E+01 %
  [------------------------------------]    0%  0d 02:00:47
Traceback (most recent call last):
  File "/home/mtlab/.local/bin/sc-experiment", line 11, in <module>
    load_entry_point('ScreamingChannels==1.0', 'console_scripts', 'sc-experiment')()
  File "/home/mtlab/.local/lib/python2.7/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/home/mtlab/.local/lib/python2.7/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/home/mtlab/.local/lib/python2.7/site-packages/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/mtlab/.local/lib/python2.7/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/mtlab/.local/lib/python2.7/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/ScreamingChannels-1.0-py2.7.egg/screamingchannels/reproduce.py", line 356, in collect
    _send_plaintext(ser, plaintext)
  File "/usr/local/lib/python2.7/dist-packages/ScreamingChannels-1.0-py2.7.egg/screamingchannels/reproduce.py", line 230, in _send_plaintext
    _send_parameter(ser, 'p', plaintext)
  File "/usr/local/lib/python2.7/dist-packages/ScreamingChannels-1.0-py2.7.egg/screamingchannels/reproduce.py", line 213, in _send_parameter
    check = ''.join(chr(int(word)) for word in ser.readline().split(' '))
  File "/usr/local/lib/python2.7/dist-packages/ScreamingChannels-1.0-py2.7.egg/screamingchannels/reproduce.py", line 213, in <genexpr>
    check = ''.join(chr(int(word)) for word in ser.readline().split(' '))
ValueError: invalid literal for int() with base 10: 'Done\r\n'

The program in sc-experiment stops working just after the first collection of trace because it couldn't come out of the tiny_aes loop. Because when I open the device in minicom in separate terminal, I need to press q everytime to come out of the tiny_aes loop.

Please see if something can be done with this error. Meanwhile I am also trying to fix this issue.

Thank you,

Regards
Ateet

from screaming_channels.

Hi,

I am sorry I cannot reproduce the error on my side, and I have never encountered this error on stable versions of the code.

Correct behavior:

1. at the end of the first 100 encryptions the firmware prints "Done", this done is read by reproduce.py at line 365.
2. at the next iteration, reproduce.py sends the plaintext, nd then expects to read it back from the firmware, at line 213.

Erroneous behavior that you encounter:

1. the firmware prints "Done" at the end of the first 100 encryptions, but reproduce.py does not read it for some reason.
2. at the next iteration, reproduce.py sends the plaintext, then reads from the serial and finds "Done", instead of the plaintext, hence the error.
3. Because of the error reproduce.py crashes and it never exits the encryption mode, hence your need to quit manually.

Do you have any modification to reproduce.py and/or the firmware that could break the correct exchange sequence?

Best,
Giovanni

from screaming_channels.

Hi,

Could you please send me the firmware file for this nRF52832 PCA10040 device which you are using? I just want to reconfirm whether it is the error with my hex file or the reproduce.py.

I reverted the changes in reproduce.py and the firmware file but the getting errors in making the hex file now.

Thanks and regards
Ateet

from screaming_channels.

Hi,

I'd prefer to help you fix your compilation setup.

The general instructions are here. I have just updated a link that changed over time, everything should work out of the box.

However, the Makefile there is configured to compile for the BLENano v2 target, not for the PCA10040.
Fortunately, the required change is easy:

At lines 77 and 100 of blenano2/blank/armgcc/Makefile, change the flags
from -DBOARD_RBLNANO2 to -DBOARD_PCA10040, and you will get a file suitable for the PCA10040 boards.

Best,
Giovanni

from screaming_channels.

Hi,

Thanks for the update.

So , I uninstalled the whole project and started from the scratch. I changed the CFLAG and ASMFLAG values in the blenano2/blank/armgcc/Makefile from -DBOARD_RBLNANO2 to -DBOARD_PCA10040.

So, now I am getting traces as desired. And everything is working well.

I think in course of making this project I had made a lot of changes in files, because of which my program was not running properly. But the good thing is I learnt a lot about how this program is working and how the traces are being collected, as this is my first time working with Linux.

Thank you so much for helping me all through.

Regards
Ateet

from screaming_channels.

I am very happy everything works well now, and that you are now more familiar with the system.
I will close this issue, but feel free to contact me whenever you need help about screaming channels.

Best,
Giovanni

from screaming_channels.